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FOREWORD 


The  preparation  of  the  system  specification  by  the  program  office 
is  the  primary  subject  of  this  guidebook.  In  addition  to  aiding  in  the 
preparation  of  the  initial  system  specification,  this  guide  can  assist  in 
preparing  subsequent  revisions  that  may  be  necessary  as  the  acquisition 
progresses,  such  as  subtier  system  segment  specifications.  This  guidebook, 
including  Appendix  A,  can  serve  also  as  a  yardstick  for  use  by  those 
reviewing  any  system  specification,  regardless  of  the  picparer. 

The  acquisition  of  a  new  system  is  typically  arranged  to  be  the 
responsibility  of  a  single  government  organization.  The  government  office 
responsible  for  the  acquisition  of  the  new  system  usually  is  a  System 
Program  Office  (SPO).  Preliminary  system  specifications  are  prepared  first 
by  the  SPO  during  the  concept  development  phase  of  the  program.  For 
complex  Air  Force  programs,  the  program  management  directive,  and  any 
other  available  top-level  documents,  are  used  to  prepare  the  initial  draft  of 
the  system  specification.  The  system  specification  describes  the  system 
and  the  functional  requirements  for  the  system  to  whatever  extent  they 
are  known  at  the  time  the  specification  is  prepared. 

As  the  acquisition  progresses,  the  requirements  can  be  definitized 
in  greater  detail  and  allocated  to  lower-tier  elements  usually  called  system 
segments.  Each  system  segment  typically  is  arranged  to  be  the  proposed 
delivered  product  of  a  single  contractor  or  organization.  Each  system  seg¬ 
ment  specification  would  be  prepared  using  the  same  format  and  guide¬ 
lines  as  used  for  the  system  specification.  During  program  initiation,  the 
program  offices  also  may  prepare  preliminary  development  specifications 
for  the  prime  items  in  the  system  segments  and  for  critical  lower-tier 
items.  These  preliminary  specifications  form  the  basis  for  study  and  for 
the  preparation  during  subsequent  acquisition  phases  of  more  detailed 
specifications. 

For  Air  Force  programs,  AFR  65-3  and  AFSC  Pamphlet  800-7 
establish  the  general  requirement  that  program-peculiar  specifications  are 
to  be  prepared  in  accordance  with  MIL-STD-490A  that  was  issued  04  June 
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1985.  For  system  specifications,  MIL-STD-490A  makes  reference  to  Data 
Item  Description  DI-CMAN-SOOOS  for  details.  The  initial  issue  of  DI- 
CMAN-80008  had  so  many  deficiencies  and  errors  that  it  was  essentially 
unusable.  A  long  and  complex  change  and  revision  cycle  has  resulted  in 
the  "A"  revision,  D1-CMAN-80008A,  issued  29  February  1988.  The  "A" 
revision  is  clearly  flawed,  but  at  least  it  is  usable  and  may  be  interpreted 
so  that  its  problems  and  deficiencies  are  overcome. 

The  set  of  detailed  requirements  presented  in  this  guidebook 
should  be  viewed  as  the  complete  baseline  for  all  possible  space  system 
requirements.  To  make  this  guidebook  easy  to  use,  the  applicable  instruc¬ 
tions  from  MIL-STD-490A  and  D1-CMAN-80008A  have  been  extracted  and 
are  incorporated  directly  in  the  text  to  avoid  detailed  referencing.  Prob¬ 
lems  and  inconsistencies  within  D1-CMAN-80008A  and  MIL-STD-490A  are 
noted  and  resolved  as  indicated  in  the  text  to  assure  consistent  inter¬ 
pretation  by  all  users,  while  providing  exact  compliance  with  the  stated 
requirements.  Requirements  then  have  been  added  to  the  specified 
requirements  to  provide  a  complete  guide  for  the  preparation  of  a  space 
system  specification. 

Although  the  emphasis  and  added  details  in  the  guidebook  are 
primarily  for  Air  Force  space  systems,  it  should  be  clear  that  the  guide¬ 
book  can  be  used  easily  to  prepare  a  system  specification  for  any  type  of 
system.  Other  types  of  systems  might  have  requirements  for  aircraft, 
missiles,  tanks,  or  ships  that  would  result  in  other  added  categories  instead 
of  requirements  for  space  vehicles.  In  that  case,  in  place  of  requirements 
in  the  guidebook  that  were  added  to  accommodate  space  vehicles,  another 
type  of  system  instead  might  include  requirements  applicable  to  aircraft, 
missiles,  tanks,  or  ships.  Most  systems  include  ground  equipment;  but 
even  there  the  actual  requirements  applicable  to  the  ground  equipment 
vary  with  the  type  of  system  being  acquired.  As  outlined  in  Sections  1  and 
2,  requirements  that  are  applicable  to  the  system  under  consideration 
would  be  addressed  instead  of  the  space  vehicle  and  other  space  system 
requirements  that  are  addressed  in  the  guidebook. 
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The  requirements  for  a  system  segment  specification  in  DI-CMAN- 
80008A  and  MIL-STD-490A  are  exactly  the  same  as  for  a  system  specifi¬ 
cation.  This  means  that  although  the  guidebook  is  primarily  for  a  system 
specification,  it  can  be  used  also  to  prepare  any  system  segment  specifica¬ 
tion.  As  outlined  in  Sections  1  and  2,  each  of  the  levels  of  assembly  simply 
shift  one  level  lower  for  a  system  segment  specification. 

For  the  convenience  of  the  user,  a  copy  of  Data  Item  Description 
DI-CMAN-80008A  is  included  in  Appendix  B.  Appendix  C  addresses  the 
availability  of  word  processor  diskette  copies  of  Appendix  A,  the  Model 
specification. 

Although  every  effort  was  made  to  be  correct  and  accurate,  the 
responsibility  for  the  contents  of  this  guide  resides  with  the  author. 
Publication  is  solely  for  the  convenience  of  the  technical  community  in  the 
interest  of  information  exchange. 
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1.  INTRODUCTION 


1.1  TERMINOLOGY 

The  acquisition  process  used  by  System  Program  Offices  (SPOs)  has 
remained  essentially  unchanged  for  the  last  several  years,  but  the  review 
committees  and  the  document  terminology  used  at  higher  Department  of 
Defense  (DoD)  levels  has  changed  frequently.  For  example,  a  Mission  Need 
Statement  (MNS)  now  is  used  at  the  DoD  level  as  the  initial  document  that 
starts  considerations  lor  any  major  new  program.  In  1986,  the  MNS  was 
called  the  Justification  for  Major  System  New  Start  (JMSNS);  before  1986,  it 
was  called  the  Mission  Element  Need  Statement  (MENS);  and  before  about 
1982,  it  was  called  the  Statement  of  Operational  Need  (SON).  In  accordance 
with  AFR  57-1,  Operational  Needs,  Requirements,  and  Concepts,  the  SON 
still  is  used  within  the  Air  Force  as  the  initial  document  that  starts  con¬ 
siderations  for  any  new  Air  Force  program.  When  the  Air  Force  program  is 
such  that  it  is  considered  at  the  DoD  level,  an  MNS  is  prepared  based  on  the 
SON.  Most  of  the  changes  in  the  reviews  and  the  terminology  for  docu¬ 
ments  used  at  higher  DoD  levels  have  been  attempts  to  achieve  procedural 
and  terminology  consistency  among  the  various  DoD  Components  and  to 
align  the  acquisition  process  with  the  Congressional  appropriations  process. 
Although  history  does  not  provide  much  assurance,  it  is  believed  that 
future  changes  will  be  minor,  or  at  least  they  will  not  affect  the  major  con¬ 
tent  of  this  guidebook.  The  current  terminology,  policies,  and  procedures 
for  the  acquisition  of  major  new  systems  are  given  in  DoD  Directive  5000.1 
and  in  DoD  Instruction  5000.2. 

1.2  PROGRAM  INITIATION 


Each  DoD  Component  has  a  requirement  for  continuing  analysis  of 
its  mission  area  to  reveal  deficiencies  and  to  determine  more  effective 
means  of  performing  its  assigned  tasks.  When  new  mission  needs  are 
identified  within  the  Air  Force,  they  are  documented  in  a  SON  or  for  DoD 
level  considerations  in  an  MNS.  The  MNS  is  reviewed  and  coordinated 
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through  appropriate  DoD  channels;  after  approval,  the  MNS  becomes  the 
basis  for  studies  and  acquisitions  that  will  satisfy  the  mission  need.  Before 
the  acquisition  of  a  major  new  system  can  begin,  approval  by  the  Defense 
Acquisition  Board  (DAB)  is  required.  The  start  and  milestone  progress  of 
major  new  systems  are  considered  by  the  DAB  concurrent  with  the  Office 
of  the  Secretary  of  Defense  Orbital  Support  Document  (OSD)  Program 
Objective  Memorandum  (POM)  review.  Approval  by  the  DAB  for  the  start 
of  a  major  new  system  is  based  on  the  need  to  satisfy  a  specific  major 
deficiency  within  a  Component's  mission  area  as  documented  in  an  MNS 
and  the  reviews  and  recommendations  of  the  appropriate  DAB  Acquisition 
Committee(s).  An  Acquisition  Decision  Memorandum  (ADM)  is  issued 
promptly  following  DAB  meetings  to  the  Head  of  the  DoD  Component(s) 
involved  in  order  to  document  the  decisions  and  approvals  reached.  Initial 
approval  of  a  major  new  system  by  the  DAB  is  identified  as  the  Milestone 
0  -  Program  Initiation/Mission-Need  Decision,  and  the  concept  exploration/ 
definition  phase  of  the  acquisition  process  follows.  The  Acquisition 
Decision  Memorandum  and  the  associated  Mission  Need  Statement  serve  as 
the  top-level  DoD  documents  governing  the  program  activities  within  the 
assigned  DoD  Components  for  the  Concept  Exploration/Definition  Phase. 

For  major  Air  Force  programs,  the  internal  top-level  program 
document  is  the  Program  Management  Directive  (PMD)  issued  by  the 
Secretary  of  the  Air  Force  based  upon  the  applicable  ADM.  Like  the  ADM, 
the  PMD  addresses  administrative  as  well  as  some  technical  issues.  The 
PMD  is  intended  to  impose  the  program  requirements  on  the  Air  Force 
organizations  involved.  It  also  documents  the  general  agreements  of  the 
Air  Force  with  other  government  organizations  that  will  participate  in  the 
program.  The  initial  issue  of  a  PMD  formally  starts  the  program  acquisi¬ 
tion.  This  initial  issue  also  is  the  basis  for  establishing  the  SPOs  and  for 
appointing  a  program  manager  for  each  SPO.  This  initial  issue  also  is  the 
basis  for  the  preparation  of  the  System  Operational  Requirement  Document 
(SORD)  by  the  lead  operating  command  in  accordance  with  AFR  57-1, 
Operational  Needs,  Requirements,  and  Concepts.  For  selected  Air  Force 
acquisition  programs,  another  formal  top-level  program  baseline  document 
also  is  prepared  that  expands  the  PMD.  This  top-level  document  is  the 
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Program  Baseline  Document  (PBD)  prepared  in  accordance  with  APR  800- 
25,  Acquisition  Management. 

1.3  SYSTEM  OPERATIONAL  REQUIREMENT  DOCUMENT 

1.3.1  General 

The  System  Operational  Requirement  Document  (SORD)  is  prepared 
in  accordance  with  APR  57-1  for  each  funded  program  to  serve  as  a  pro¬ 
gram  planning  document  that  identifies  the  top-level  performance,  opera¬ 
tion,  and  support  parameters,  characteristics,  and  requirements  for  the 
system.  It  documents  how  the  system  will  be  operated,  deployed,  em¬ 
ployed,  and  supported  and  provides  initial  guidance  for  the  implementing, 
supporting,  and  participating  commands  and  agencies.  The  SORD  is  pre¬ 
pared  by  the  lead  operating  command  during  the  Concept  Exploration/ 
Definition  Phase  of  the  program  acquisition.  The  SORD  then  is  updated  by 
the  lead  operating  command  during  each  subsequent  phase  of  the  program 
acquisition  to  reflect  any  changes  in  the  requirements  and  any  cost  and 
performance  tradeoffs. 

1.3.2  Content 

An  SORD  is  prepared  in  five  parts,  with  two  mandatory  attach¬ 
ments,  in  accordance  with  APR  57-1. 

Part  I  of  a  System  Operational  Requirement  Document,  "Mission,"  very  briefly  addresses  the 
mission  area,  the  mission  element  need,  and  any  joint-service  or  multinational  applicability  of  the 
program  or  system  being  developed. 

Part  II  of  a  System  Operational  Requirement  Document,  "Basis  of  Need,"  addresses  tfie  new 
information,  threat  change,  or  technology  opportunity  that  form  the  basis  for  the  need. 

Part  III  of  a  System  Operational  Requirement  Document,  "Assessment  of  Capability," 
summarizes  the  existing  and  the  planned  capability,  focusing  primarily  on  the  shortfalls  of  the 
existing  capability  to  meet  the  threat. 
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Part  IV  of  a  System  Operational  Requirement  Document,  "Needed  Capability,"  is  the  body  of  the 
document  that  addresses  the  following  areas  in  considerable  detail: 


a.  General  Operational  Requirements.  (A  list  of  the  critical  requirements  described  in  these 
paragraphs  that  form  the  basis  of  the  first  mandatory  attachment,  i.e.  the  Requirements 
Correlation  Matrix) 

b  Related  Support  Factors 

a  Possible  Solutions 

d.  Upgraded  System  Description  (if  applicable) 

a  New  System  Description  (if  applicable) 

f.  Any  Other  Solutions  (if  applicable) 

Part  V  of  a  System  Operational  Requirement  Document,  "Proposed  Program,"  describes  the 
acquisition  strategy,  the  schedule,  and  the  funding  profile. 

Attachment  1  of  a  System  Operational  Requirement  Document,  "The  Requirements  Correlation 
Matrix  (RCM),"  traces  each  of  the  critical  parameters  from  values  stated  in  the  initial 
Statement  of  Need,  through  the  values  stated  in  each  version  of  the  System  Operational 
Requirement  Document,  in  terms  of  specification  values  and  test  criteria. 

Attachment  2  of  a  System  Operational  Requirement  Document,  "Threat  Assessment,"  also  is 
mandatory. 

Attachment  3  of  a  System  Operational  Requirement  Document,  "Funding,"  is  prepared  if  the 
funding  information  is  too  extensive  to  include  in  the  text. 

1.4  PROGRAM  BASELINE  DOCUMENT 

1.4.1  General 

A  Program  Baseline  Document  (PBD)  is  prepared  for  selected 

programs  to  serve  as  a  program  integration  document  that  identifies  the 
top-level  program  requirements  and  allocates  those  requirements  to  the 
various  independent  government  organizations  involved. 
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1.4.2  Content 


A  PBD  is  prepared  in  three  parts  in  accordance  with  APR  800-25, 
"Acquisition  Management." 

Part  I  of  a  Program  Baseline  Document,  "Requirements,"  describes  the  need  for  the  program  or 
system  being  developed  and  identifies  by  reference  the  source  documents,  such  as  Statement  of 
Need  (SON),  Mission  Need  Statement  (MNS),  Joint  Strategic  Operational  Requirement  (JSOR), 
System  Operational  Requirement  Documefit  (SORD),  System  Operational  Concept  (SOC), 
Information  Systems  Requirements  Document  (ISRD),  Functional  Description  (FD),  et  cetera, 
which  contain  the  operational  and  supportability  requirements  the  program  is  to  satisfy. 

Part  II  of  a  Program  Baseline  Document,  "Program  Content,"  describes  the  program  being 
pursued.  It  is  subdivided  into  major  sections  such  as: 

A.  System  Definition 

B.  Performance 

C.  Operations  Concept 

D.  System  Readiness 

E  Integrated  Logistics  Support 

F.  Maintenance  Concept 

G.  Communications,  Data  Automation,  and  Information  Systems 
Resources 

H.  Test  and  Evaluation 
I  Training 

J.  Facilities 

K.  Acquisition  Strategy 
L  Schedule 

Part  III  of  a  Program  Baseline  Document,  "Approved  Funding,”  identifies  the  program  funding 
approved  in  the  Congressional  Appropriations  Bill  and  in  the  Five-Year  Defense  Program. 
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When  the  Program  Baseline  Document  is  signed  by  all  the  program 
participants  and  HQ  USAF,  it  becomes  the  formal  Program  Baseline  Agree¬ 
ment.  When  a  PBD  is  not  prepared  or  when  it  does  not  cover  specific 
details,  it  should  be  recognized  that  other  formal  interagency  coordination 
documentation  may  be  needed  to  avoid  subsequent  misunderstandings. 
Requirements,  even  if  coordinated  at  a  technical  level,  cannot  be  unilat¬ 
erally  imposed  on  one  government  organization  by  another  independent 
government  organization.  The  cooperative  program  activities  required 
among  the  government  organization^  involved  can  be  assured  only  by 
signed  agreements.  Interagency  requirements  that  are  not  included  in  a 
Program  Baseline  Agreement  usually  are  documented  by  "memoranda  of 
agreement,"  "memoranda  of  understanding,"  "interface  control  documents," 
or  any  combination  of  these. 

1.5  ACOIITSITIQN  POLICY 

The  general  acquisition  management  policies  to  be  followed  by  the 
SPOs  and  the  program  managers  within  the  Air  Force  Space  Systems  Divi¬ 
sion  (SSD)  are  stated  in  AFR  800-2,  Acquisition  Program  Management, 

This  Air  Force  regulation  implements  requirements  to  follow  applicable 
DoD  directives  on  major  system  acquisitions,  identifies  the  various  program 
phases,  and  establishes  formal  decision  milestones  during  the  program  life 

cycle.  The  specific  acquisition  strategy  to  be  followed  is  determined  by  an 

Acquisition  Strategy  Panel  (AFSC  Regulation  550-21,  Acquisition  Strategy) 
and  is  documented  in  the  Acquisition  Plan. 

1.6  APPROACH  TO  SPECTHCATIQN  PREPARATION 

As  shown  in  Figures  1  and  2,  several  system  specifications  are 
typically  required  to  describe  all  of  the  requirements  of  a  major  DoD 
program.  In  the  space  program  shown,  the  program  includes  not  only  the 
on-orbit  space  system,  but  also  the  launch  system  and  other  associated 
systems  such  as  the  satellite  control  network  system  for  tracking  and 
commanding  the  satellite,  a  wide-band  communications  system,  and 
perhaps  other  systems.  Each  of  the  system  specifications  is  typically 
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prepared  by  a  different  government  organization  or  at  least  by  an  inde¬ 
pendent  SPO.  Figure  1  shows  that  the  on-orbit  space  system  for  the 
program  illustrated  has  been  subdivided  into  three  system  segments  plus 
other  possible  system  segments  that  have  not  been  identified.  Figure  2 
shows  that  the  launch  system  for  the  program  illustrated  has  been  sub¬ 
divided  into  two  system  segments  plus  other  possible  system  segments 
that  have  not  been  identified.  The  specifications  that  are  the  responsibility 
of  a  single  SPO,  including  subtier  system  segment  specifications,  are  shown 
with  solid  lines.  Specifications  for  interfacing  elements  are  shown  with 
dashed  lines.  Although  the  space  vehicle  really  is  the  payload  of  the 
launch  vehicle,  and  therefore  is  a  critical  element  of  the  actual  launch 
system,  it  is  shown  by  dashed  lines  in  Figure  2  as  an  interfacing  element  to 
the  launch  system,  since  it  is  defined— at  least  in  this  case— as  part  of  the 
on-orbit  space  system. 

Each  of  the  government  organizations  involved  prepares  a  system 
specification  for  the  procurement  of  its  portion  of  the  total  program.  These 
system  specifications  are  based  on  the  PMD,  the  SORD,  and,  if  available,  the 
Program  Baseline  Agreement.  The  equipment  and  software  requirements 
in  each  system  specification  may  be  subdivided  by  the  responsible  pro¬ 
gram  office  into  separate  functional  areas  identified  as  system  segments 
or,  for  simple  systems,  directly  into  prime  items. 

A  system  segment  is  simply  a  major  element  of  a  system  that  is  so 
identified  by  the  responsible  program  office  for  management  expediency 
or  to  facilitate  separate  procurements.  When  system  segments  are  identi 
fied  by  the  program  office,  they  should  be  identified  also  in  the  system 
specification.  A  system  segment  should  included  the  delivered  products  of 
a  single  contractor  or  organization.  For  example,  a  space  vehicle  system 
segment  typically  would  include  the  space  vehicle  as  well  as  the  ground 
support  equipment  for  the  vehicle,  interfacing  equipment  to  be  carried  in 
the  Space  Transportation  System  Orbiter  (if  used),  and  other  items  to  be 
delivered  by  the  space  vehicle  contractor. 
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Figure  1.  Typical  On-Orbit  Space  System  Specification  Tree 
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Figure  2.  Typical  Launch  System  Specification  Tree 
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The  system  and  system  segment  specifications  form  the  technical 
basis  for  procurements  conducted  by  the  SPO  responsible  for  the  system 
acquisition.  For  that  reason,  each  system  specification  documents  only 
those  program  functions  and  requirements  allocated  to  the  SPO  or  govern¬ 
ment  organization  preparing  that  system  specification.  The  interfacing 
system  or  system  segment  specifications  required  to  define  external  inter¬ 
faces  may  not  actually  exist  when  they  are  required  for  the  preparation  of 
the  system  specification,  because  the  "cooperating"  independent  govern¬ 
ment  organizations  responsible  for  their  preparation  may  not  have  given 
the  task  a  high  enough  priority,  or  they  simply  may  have  not  been 
designed.  Deficiencies  in  the  availability  of  reference  documents  make  it 
difficult  to  prepare  a  complete  system  specification,  but  they  should  not 
abort  the  effort.  The  system  specification  should  be  as  complete  as 
possible  under  the  circumstances  that  exi^t  when  it  is  prepared. 

To  illustrate  typical  program  complexity,  an  Air  Force  meteoro¬ 
logical  satellite  vehicle  may  be  launched  by  the  National  Aeronautics  and 
Space  Administration  (NASA)  Space  Transportation  System  (STS)  to 
produce  data  to  be  used  in  the  Department  of  Commerce  weather  fore¬ 
casting  system.  The  preparation  of  the  various  system  specifications 
required  to  describe  this  total  program  would  be  the  responsibility  of  the 
various  government  organizations  involved.  NASA  would  document  the 
STS  in  system  and  subtier  specifications,  the  Department  of  Commerce 
would  document  the  data  system  for  worldwide  exchange  of  weather  data 
and  forecasts,  and  the  DoD  would  prepare  a  space  system  specification  for 
the  acquisition  of  the  satellite  system. 

1.7  APPROACH  TO  SYSTEM  SPECIHCATION  CONTENT  AND 

FORMATTING 

The  general  content  and  format  requirements  for  the  preparation 
of  program-peculiar  specifications  for  DoD  programs  are  covered  in  MIL- 
STD-490A,  dated  04  June  1985.  For  Air  Force  programs,  either  Form  la 
specifications  or  Form  lb  specifications  as  defined  in  MIL-S-83490  may  be 
used.  Form  la  requires  strict  format  compliance  with  military  standards, 
whereas  Form  lb  requires  only  limited  format  compliance.  However,  Form 
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la  allows  the  addition  of  new  paragraphs  for  added  subjects  as  long  as  the 
added  paragraphs  follow  the  stipulated  paragraphs  in  each  section,  so  that 
the  stipulated  paragraphs  do  not  require  renumbering.  Because  the  tech¬ 
nical  content  of  a  Form  lb  specification  should  be  the  same  as  the  technical 
content  of  a  Form  la  specification,  the  government  usually  requires  a  Form 
la  specification,  since  using  a  standard  format  should  not  cost  any  extra 
money.  On  the  other  hand,  using  a  Form  lb  specification  should  not  cause 
any  major  problems  for  the  government. 

In  the  terminology  of  the  referenced  standards,  a  system  specifi¬ 
cation  is  a  Type  A  specification,  and  its  preparation  is  covered  in  Appendix 
I  of  MIL-STD-490A.  Although  it  may  be  difficult  to  follow.  Appendix  I  of 
MIL-STD-490A  references  Data  Item  Description  DI-CMAN-80008  that 
provides  most  of  the  details.  Problems  and  inconsistencies  within  DI- 
CMAN-80008  and  with  MIL-STD-490A  meant  that  DI-CMAN-80008  was 
really  impossible  to  use;  so  Revision  A,  dated  29  February  1988,  was 
prepared  and  released.  Problems  and  inconsistencies  still  exist  with  this 
revision,  DI-CMAN-80008A;  however,  strict  format  compliance  can 
generate  a  suitable  system  specification,  provided  the  inconsistencies  are 
properly  resolved.  Towards  that  end,  the  detailed  requirements  in  Data 
Item  Description  DI-CMAN-80008A  and  the  general  requirements  in  MIL- 
STD-490A  have  been  extracted  and  are  included  in  this  guide  to  avoid 
referencing  and  to  resolve  possible  problems.  If  a  contractor  is  tasked  to 
prepare  a  system  specification  and  this  guide  cannot  be  followed  for  some 
reason,  it  is  recommended  that  the  specification  be  prepared  as  Form  lb. 

In  that  way,  the  contractor  will  have  some  flexibility  in  the  format  used. 

In  any  case,  DO  NOT  TRY  TO  FOLLOW  THE  ORIGINAL  VERSION  OF  THE  DATA 
ITEM  DESCRIPTION,  DI-CMAN-80008,  SINCE  IT  IS  NOT  USABLE. 

In  order  to  instill  a  discipline  to  not  state  detailed  requirements 
too  early  in  the  acquisition,  the  system  specification  is  organized  with  a 
logical  expansion  in  the  detail  requested  for  requirements  as  one  pro¬ 
gresses  from  Section  1,  Scope;  to  Section  3.1,  Definition;  to  general  require¬ 
ments  in  Subsections  3.2,  3.3,  3.4,  3.5,  and  3.6;  and  finally  to  Subsection 
3.7,  Subtier  Requirements.  This  expansion  allows  the  first  sections  to  be 
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completed  early  in  the  acquisition,  with  little  expectation  that  completed 
sections  subsequently  would  require  major  changes. 

1.8  ADDED  SPECIFICATION  REQUIRFMENTS  FOR  SPACE  SYSTEMS 

For  a  space  system,  it  is  cost  effective  to  add  "lesson  learned" 
requirements  that  are  not  specifically  addressed  in  the  general  system 
specification  format  to  help  avoid  repeated  failures.  In  this  guidebook, 
space  system  requirements  missing  in  MIL-STD-490A  and  DI-CMAN- 
80008A  have  been  added  to  the  specified  requirements  to  provide  a 
complete  guide  for  the  preparation  of  space  system  specifications.  There¬ 
fore,  the  content  requirements  and  format  presented  in  this  guide  assure 
both  compliance  with  MIL-STD-490A  and  DI-CMAN-80008A  and  coverage 
of  the  critical  and  unique  requirements  for  space  systems.  In  other  words, 
this  guide  should  be  followed  exactly  to  obtain  a  Form  la  space  system 
specification. 

1.9  ADDED  REQUIREMENTS  FOR  OTHER  TYPES  OF  SYSTEMS 

Although  the  emphasis  and  added  details  in  the  guidebook  are 
primarily  for  Air  Force  space  systems,  it  should  be  clear  that  the 
guidebook  can  be  used  easily  to  prepare  a  system  specification  for  any 
type  of  system.  Another  type  of  system,  and  perhaps  some  space  systems, 
might  have  requirements  for  other  classes  of  items,  such  as  aircraft,  mis¬ 
siles,  balloons,  tanks,  or  ships,  that  need  to  be  included.  In  that  case,  in 
place  of  requirements  in  the  guidebook  for  a  space  vehicle,  another  type  of 
system  might  include  requirements  for  the  other  applicable  classes  of 
items,  such  as  aircraft,  missiles,  balloons,  tanks,  or  ships. 

Of  course,  almost  all  systems  include  ground  equipment,  so 
provisions  for  ground  equipment  requirements  would  be  expected  in  all 
system  specifications.  Other  classes  of  requirements  that  are  applicable  to 
the  system  under  consideration  would  be  addressed  instead  of,  or  in 
addition  to,  the  space  vehicle  requirements  that  actually  are  addressed  in 
the  guidebook.  This  would  require  some  paragraph  renumbering  in  the 
guidebook,  and  some  paragraphs  would  have  different  titles;  but  the 
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changes  would  be  at  subtler  levels  that  should  not  affect  compliance  with 
DI-CMAN-80008A  and  MIL-STD-490A. 

1.10  APPROACH  TO  SYSTEM  SEGMENT  SPECTHCATION  PREPARATION 

The  requirements  for  a  system  segment  specification  in  DI-CMAN- 
80008A  and  MIL-STD-490A  are  exactly  the  same  as  for  a  system  specifi¬ 
cation.  This  means  that  although  the  guidebook  is  primarily  for  a  system 
specification,  it  can  be  used  also  to  prepare  any  system  segment  specifi¬ 
cation.  The  levels  of  assembly  simply  shift  one  level  lower.  The  term 
"configuration  item"  always  replaces  "prime  item."  The  term  "prime  item" 
always  replaces  "system  segment."  The  term  "system  segment  specifi¬ 
cation"  always  replaces  "system  specification."  The  term  "system  segment" 
replaces  "system"  in  many  places;  but  one  must  read  the  text  to  be  sure, 
since  the  correct  word  still  could  be  "system"  in  some  cases.  Almost  all 
system  segments  include  ground  equipment,  so  provisions  for  ground 
equipment  requirements  would  be  expected  in  all  system  segment  specifi¬ 
cations.  Except  for  space  vehicle  system  segment  specifications,  a  typical 
system  segment  does  not  include  requirements  for  a  space  vehicle.  The 
requirements  shown  in  the  guidebook  for  a  space  vehicle  then  would  be 
deleted;  however,  there  might  be  added  requirements  for  other  classes  of 
items,  such  as  aircraft,  missiles,  balloons,  tanks,  or  ships,  that  would  be 
addressed  instead  of  the  space  vehicle  requirements.  In  any  case,  this 
would  result  in  some  paragraph  renumbering,  and  some  paragraphs  would 
have  different  titles;  but  the  changes  should  be  at  subtier  levels  that  would 
not  affect  compliance  with  D1-CMAN-80008A  and  MIL-STD-490A. 
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2.  SYSTEM  SPECDFICATION  PREPARATION 
2.1  SPACE  SYSTEM  MODEL  SPECIHCATION 

A  model  of  a  space  system  specification  giving  the  format  and 
standard  boilerplate  requirement  statements  for  each  section  is  included 
as  Appendix  A  of  this  guidebook.  In  other  words,  Appendix  A  is  a  model 
specification  which  states  typical  requirements  that  would  be  expected  in 
all  space  system  specifications.  By  adding  the  program-peculiar  require¬ 
ments  to  the  boilerplate  requirements  given  in  this  model  specification,  a 
complete  space  system  specification  can  be  quickly  and  competently  pre¬ 
pared  for  any  program.  To  highlight  some  of  the  paragraphs  in  the  model 
specification  where  program-peculiar  requirements  should  be  added,  the 
acronym  TBS  is  used  to  indicate  "to  be  supplied"  by  the  government.  The 
body  of  this  guide  summarizes  pertinent  comments  and  requirements  for 
preparing  these  supplementary  program-peculiar  requirements  for  the 
various  subparagraphs. 

Note  that  the  level  of  technical  detail  increases  substantially  during 
the  acquisition  process.  In  the  initial  phases  of  a  program,  after  the 
program-peculiar  requirements  have  been  added  to  the  boilerplate 
requirements  in  this  model  specification,  requirements  still  may  not  be 
firm  or  may  not  have  been  identified  for  many  of  the  headings  in  the 
specification.  In  those  cases,  it  is  recommended  that  all  paragraph  head¬ 
ings  be  retained  but  that  a  notation  be  made  to  indicate  the  government's 
intent.  If  there  are  no  requirements  that  have  been  defined  or  that  are 
applicable  for  a  paragraph  at  the  time  the  system  specification  is  prepared, 
the  acronym  "TBS"  may  be  added  after  the  heading  to  mean  that  the  miss¬ 
ing  requirement  is  "to  be  supplied"  by  the  government  in  the  course  of  the 
acquisition.  Alternatively,  the  missing  requirement  may  be  marked  "TBD" 
(to  be  determined)  or  "Not  applicable."  The  acronym  "TBD"  would  be 
added  to  a  missing  requirement  to  mean  that  the  missing  requirement  is 
"to  be  determined"  by  the  contractor  in  coordination  with  the  government. 
"Not  applicable"  would  be  added  to  mean  that  there  are  no  requirements 
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stated,  and  none  are  anticipated  by  the  government.  The  intent  is  to 
format  the  initial  draft  of  the  specification  so  that  substantial  renumbering 
of  the  major  paragraphs  in  the  document  will  not  occur  as  additional 
details  become  available  during  the  acquisition  process. 

If  a  stated  requirement  is  not  considered  firm  at  the  time  the 
system  specification  is  prepared,  the  requirement  may  be  stated  using 
"weighting  factor"  terminology  as  discussed  in  the  text  for  Paragraph  3.8.2, 
Requirement  Weighting  Factors,  or  the  requirement  may  be  annotated 
with  a  (TBR).  The  acronym  "TBR"  added  to  a  requirement  would  mean  that 
the  requirement  is  "to  be  reviewed"  for  appropriateness  by  the  contractor 
or  the  governmiat,  and  may  be  changed  by  the  government  in  the  course 
of  the  acquisition.  The  purpose  of  this  is  to  prepare  the  specification  in 
ways  that  convey  the  maximum  information  to  those  doing  trade  studies 
and  allocating  requirements  to  subtier  elements. 

The  Model  Space  System  Specification,  Appendix  A,  was  prepared 
as  a  Form  la  specification  using  the  format  shown  in  Figure  3  (and 
presented  in  expanded  detail  in  Section  3).  This  format  exactly  follows  the 
format  of  DI-CMAN-80008A  and  MIL'STD-490A.  Paragraphs  that  have 
been  added  to  accommodate  the  unique  requirements  of  space  systems  are 
indicated  by  an  asterisk  (*).  This  format  generally  is  common  with  other 
specification  formats  established  by  MIL-STD-490A,  so  that  it  provides  a 
good  basis  for  the  preparation  of  lower-tier  specifications.  This  last  point 
is  significant,  since  the  use  of  a  common  format  for  the  system  specifica¬ 
tion,  the  system  segment  specifications,  and  subsequent  lower-tier  devel¬ 
opment  specifications  has  clear  advantages  to  those  preparing  the  lower- 
tier  specifications.  It  means  that  the  allocation  of  requirements  from  the 
top-level  specifications  to  lower-tier  specifications  is  primarily  on  a  para¬ 
graph  to  corresponding  paragraph  basis.  It  also  simplifies  the  program 
management  review  of  contractor-prepared  specifications  for  subtier 
items,  because  requirement  allocation  verification  and  traceability  of 
requirements  between  higher-  or  lower-tier  specifications  is  more 
straightforward.  The  desired  use  of  a  common  format  does  require  an 
increase  in  detail  of  the  specified  format  for  the  subsections  of  the  system 
specification,  particularly  subsections  of  Section  4,  Quality  Assurance. 
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However,  in  addition  to  the  other  advantages,  the  increased  detail  in 
Section  4  allows  for  and  encourages  the  identification  of  special  tests  and 
the  identification  of  related  test  equipment  as  early  as  possible  in  the 
acquisition  cycle.  The  early  definition  of  these  requirements  permits 
better  design  and  scheduling  of  the  special  test  equipment  and  test 
facilities  required  by  manufacturing  and  the  field  organizations  than  would 
otherwise  be  possible.  The  requirements  in  Section  4  of  the  specification 
also  should  provide  the  technical  basis  for  the  imposition  of  required 
quality  levels  and  quality  management  systems  in  the  Statement  of  Work 
(SOW)  or  contract. 

2.2  SPACE  SYSTEM  SPECIHCATIQN  PREPARATION  STEPS 

For  the  convenience  of  those  preparing  a  space  system  specifica¬ 
tion,  a  copy  of  the  model  specification  (Appendix  A)  and  a  copy  of  the 
entire  guidebook  are  available  on  a  diskette  at  the  back  of  this  report  for 
use  on  word  processing  systems.  Because  revisions  to  the  guidebook  and 
to  the  model  specification  will  be  made  from  time  to  time,  it  is  advisable  to 
obtain  the  latest  copy  prior  to  any  serious  applications. 

The  recommended  sequential  steps  in  preparing  a  space  system 
specification  for  a  major  new  program  are: 

a.  Obtain  a  diskette  copy  of  the  Model  space  system  specification. 
Appendix  A,  for  use  on  word  processing  systems,  and  print  a 
copy  on  your  word  processing  system  to  be  sure  of  your  start¬ 
ing  point. 

b.  Obtain  a  copy  of  the  available  top-level  program  documents 
such  as  the  SORD,  the  PBD  if  prepared,  the  PMD,  the  ADM,  and 
the  MNS. 

c.  Extract  the  applicable  technical  requirements  for  the  system 
from  the  top-level  program  documents  and  add  them,  in 
applicable  paragraphs  as  outlined  in  Section  3  of  this  guide¬ 
book,  to  the  Model  system  specification  to  obtain  a  draft 
system  specification  for  the  system. 
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d.  Check  each  paragraph  of  the  resulting  draft  system  specifica¬ 
tion  with  the  general  requirements  outlined  in  Section  3  of  this 
guidebook  in  order  to  assure  content  and  format  compliance. 

e.  Verify  all  requirements  in  each  paragraph  of  the  draft  system 
specification  against  program  need  in  order  to  assure  their 
applicability  to  the  program. 

f.  Update  the  reference  documents  listed  in  Section  2  of  the 
resulting  draft  system  specification  by  including  all  added 
documents  (and  by  deleting  those  no  longer  referenced). 

Verify  and  update  to  the  latest  revisions,  notices,  and  dates  of 
issue  [see  the  DoD  Intelligence  Information  System  (DoDISS)]. 

g.  Update  the  table  of  contents  of  the  resulting  draft  system 
specification. 

h.  Print  a  coordination  copy  of  the  resulting  draft  system 
specification  for  formal  review. 

The  number  of  people  involved  in  preparing  this  coordination  copy 
of  the  draft  system  specification  for  a  major  new  program  should  be  kept 
to  a  minimum.  Above  all,  never  ask  50  or  so  different  experts  to  each 
prepare  a  paragraph  for  one  of  the  50  or  so  different  subject  or  functional 
areas  in  the  specification,  expecting  to  staple  the  paragraphs  together  to 
obtain  the  draft  specification.  That  process  never  can  produce  a  consistent 
and  technically  valid  specification.  Always  start  with  a  good  baseline  (i.e., 
the  Model  specification).  When  the  draft  specification  is  ready,  have  the 
50  or  so  different  experts  on  the  coordination  list  review  it  and  prepare 
comments.  Note  that  it  is  impossible  to  provide  valid  comment  on  a  single 
paragraph  extracted  from  the  draft  specification.  Everyone  involved  with 
the  coordination  and  review  should  have  the  entire  specification,  even  if 
they  are  expected  to  review  and  comment  on  only  a  single  paragraph.  In 
fact,  for  a  good  specification  review,  each  expert  needs  to  have  available, 
or  be  familiar  with,  the  top-level  program  documents  such  as  the  SORD,  the 
PBD,  the  PMD,  the  ADM,  and  the  MNS. 
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Although  the  emphasis  and  added  details  in  the  guidebook  are 
primarily  for  Air  Force  space  systems,  it  should  be  clear  that  the  guide¬ 
book  can  be  used  easily  to  prepare  a  system  specification  for  any  type  of 
system.  The  recommended  sequential  steps  in  preparing  a  system  speci¬ 
fication  for  a  major  new  program  that  is  rot  a  space  system  are: 

a.  Obtain  a  diskette  copy  of  the  Model  space  system  specification 
(Appendix  A)  for  use  on  word  processing  systems,  and  print  a 
copy  on  your  word  processing  system  to  be  sure  of  your  start¬ 
ing  point. 

b.  Obtain  a  copy  of  the  available  top-level  program  documents 
such  as  the  SORD,  the  PBD  if  prepared,  the  PMD,  the  ADM,  and 
the  MNS. 

c.  Verify  the  general  requirements  in  the  draft  system  specifica¬ 
tion  against  the  program  need  in  order  to  assure  their  applic¬ 
ability  to  the  program.  Delete  space  vehicle"  requirements  and 
add  paragraphs  for  other  applicable  types  of  equipment,  such 
as  aircraft,  missiles,  balloons,  tanks,  or  ships,  to  obtain  a  Model 
system  specification  for  the  system. 

d.  Extract  the  applicable  technical  requirements  for  the  system 
from  the  top-level  program  documents  and  add  them,  in 
applicable  paragraphs  as  outlined  in  Section  3  of  this 
guidebook,  to  the  Model  system  specification  generated  in  "c" 
above  in  order  to  obtain  a  draft  system  specification  for  the 
system. 

e.  Check  each  paragraph  of  the  resulting  draft  system  specifica¬ 
tion  with  the  general  requirements  outlined  in  Section  3  of  this 
guidebook  to  assure  content  and  format  compliance. 

f.  Verify  all  requirements  in  each  paragraph  of  the  draft  system 
specification  against  program  need  in  order  to  assure  their 
applicability  to  the  program. 
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g.  Update  the  reference  documents  listed  in  Section  2  of  the 
resulting  draft  system  specification  by  including  all  added 
documents  (and  by  deleting  those  no  longer  referenced). 

Verify  and  update  to  the  latest  revisions,  notices,  and  dates  of 
issue  (see  the  DoDISS). 

h.  Update  the  table  of  contents  of  the  resulting  draft  system 
specification. 

i.  Print  a  coordination  copy  of  the  resulting  draft  system 
specification  for  formal  review. 

The  number  of  people  involved  in  preparing  this  coordination  copy 
of  the  draft  system  specification  for  a  major  new  program  should  be  kept 
to  a  minimum.  Above  all,  never  ask  50  or  so  different  experts  to  each 
prepare  a  paragraph  for  one  of  the  50  or  so  different  subject  or  functional 
areas  in  the  specification,  expecting  to  staple  the  paragraphs  together  to 
obtain  the  draft  specification.  That  process  never  can  produce  a  consistent 
and  technically  valid  specification.  Always  start  with  a  good  baseline  (i.e., 
the  Model  specification).  When  the  draft  specification  is  ready,  have  the 
50  or  so  different  experts  on  the  coordination  list  review  it  and  prepare 
comments.  Note  that  it  is  impossible  to  provide  valid  comment  on  a  single 
paragraph  extracted  from  the  draft  specification.  Everyone  involved  with 
the  coordination  and  review  should  have  the  entire  specification,  even  if 
they  are  expected  to  review  and  comment  on  only  a  single  paragraph.  In 
fact,  for  a  good  review,  each  expert  needs  to  have  available,  or  be  familiar 
with,  the  top-level  program  documents  such  as  the  SORD,  the  PBD,  the  PMD, 
the  ADM,  and  the  MNS. 

2.4  PREPARATION  STEPS  FOR  A  SYSTEM  SEGMENT  SPECIFICATION 

The  requirements  for  a  system  segment  specification  in  DI-CMAN- 
80008A  and  MIL-STD-490A  are  exactly  the  same  as  for  a  system  specifi¬ 
cation.  This  means  that  although  the  guidebook  is  primarily  for  a  system 
specification,  it  can  be  used  also  to  review  or  to  prepare  any  system  seg¬ 
ment  specification.  The  levels  of  assembly  identified  in  a  system  specifica¬ 
tion  simply  shift  one  level  lower  in  a  system  segment  specification. 
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To  generate  a  guidebook  for  preparing  a  system  segment  specifi¬ 
cation  from  Section  3  of  this  report,  the  term  "configuration  item"  always 
replaces  "prime  item."  The  term  "prime  item"  always  replaces  "system 
segment."  The  term  "system  segment  specification"  always  replaces 
"system  specification."  The  term  "system  segment"  replaces  "system"  in 
many  places,  but  one  must  read  the  text  to  check  whether  the  correct  word 
is  "system"  or  "system  segment." 

To  generate  a  "Model"  system  segment  specification  from  the 
Model  space  system  specification  (Appendix  A)  in  this  guidebook,  always 
replace  the  term  "configuration  item"  with  "prime  item."  The  term  "prime 
item"  always  replaces  "system  segment."  The  term  "system  segment 
specifica-tion"  always  replaces  "system  specification."  The  term  "system 
segment"  replaces  "system"  in  many  places,  but  one  must  read  the  text  to 
check  whether  the  correct  word  is  "system"  or  "system  segment." 

Except  for  space  vehicle  system  segment  specifications,  a  typical 
system  segment  specification  does  not  include  requirements  for  a  space 
vehicle.  The  requirements  shown  in  these  system  segment  documents  for 
a  space  vehicle  then  would  be  deleted;  however,  there  might  be  added 
requirements  for  aircraft,  missiles,  balloons,  tanks,  or  ships  that  would  be 
addressed  instead  of  the  space  vehicle  requirements.  In  any  case,  that 
would  result  in  some  paragraph  renumbering  and  some  paragraphs  would 
have  different  titles,  but  the  changes  would  be  at  subtier  levels  that  would 
not  affect  compliance  with  DI-CMAN-80008A  and  MIL-STD-490A.  The 
resulting  system  segment  specification  requirements  document  and  Model 
system  segment  specification  then  can  be  used  as  a  guide  to  prepare 
system  segment  specifications  or  to  review  system  segment  specifications 
prepared  by  others. 

The  process  is  explained  in  more  detail  in  the  following  recom¬ 
mended  sequential  steps  in  preparing  the  system  segment  specifications 
that  are  part  of  a  specific  system: 

a.  Obtain  a  diskette  copy  of  the  applicable  system  specification  for 
use  on  word  processing  systems.  If  the  applicable  system 
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specification  is  not  available,  a  draft  copy  of  the  system  specifi¬ 
cation  can  be  developed  as  described  above  and  used  as  the 
starting  point  for  preparing  the  system  segment  specifications. 
Or  the  Model  space  system  specification,  Appendix  A,  can  be 
used  as  the  starting  point  for  preparing  a  Model  space  system 
segment  specification.  In  any  case,  print  a  copy  to  be  sure  of 
your  starting  point. 

b.  The  levels  of  assembly  for  a  system  specification  simply  are 
shifted  one  level  lower  in  a  system  segment  specification.  First, 
globally  replace  the  term  "prime  item"  in  the  system  specifica¬ 
tion  with  "configuration  item."  Then,  globally  replace  the  term 
"system  segment"  in  the  system  specification  with  "prime 
item."  Then,  globally  replace  the  term  "system  specification"  in 
the  system  specification  with  "system  segment  specification." 
The  term  "system  segment"  replaces  "system"  in  many  places, 
but  one  must  read  the  text  to  check  whether  the  correct  word 
is  still  "system."  This  process  creates  a  document  in  the  format 
of  a  system  segment  specification  that  contains  all  of  the 
requirements  for  all  of  the  system  segments.  In  other  words, 
each  of  the  requirements  still  needs  to  be  allocated  to  the 
applicable  system  segments. 

c.  To  create  a  draft  specification  for  a  specific  system  segment, 
create  a  new  document  that  is  a  copy  of  the  document  that  was 
created  in  "b"  above  (that  is,  in  the  format  of  a  system  segment 
specification  and  that  contains  all  of  the  requirements  for  all  of 
the  system  segments).  Then,  using  the  results  of  trade  studies, 
system  engineering  processes,  and  common  sense,  simply 
delete  all  requirements  in  that  document  that  are  not 
applicable  or  allocated  to  that  specific  system  segment. 

A  new  document  will  need  to  be  created  for  each  of  the  system 
segment  specifications  that  are  part  of  the  system. 

The  requirements  in  Subsection  3.7  in  the  system  specification 
that  were  allocated  to  the  various  system  segments  then  will 
need  to  be  merged  into  the  other  requirements  in  the 
applicable  system  segment  specifications. 


3  1 


d:SSD-GB-4A/a:EDC-MAC-#13 


d.  Check  each  paragraph  of  the  resulting  draft  system  segment 
specifications  with  the  general  requirements  outlined  in  Sec¬ 
tion  3  of  this  guidebook  to  assure  content  and  format  compli¬ 
ance. 

e.  Verify  all  requirements  in  each  paragraph  of  the  draft  system 
segment  specifications  against  program  need  to  assure  their 
applicability  to  the  program. 

f.  Update  the  reference  documents  listed  in  Section  2  of  the 
resulting  draft  system  segment  specifications  by  including  all 
added  documents  (and  by  deleting  those  no  longer  referenced). 
Verify  and  update  to  the  latest  revisions,  notices,  and  dates  of 
issue  (see  the  DoDISS). 

g.  Update  the  table  of  contents  of  the  resulting  draft  system 
segment  specifications. 

h.  Print  a  coordination  copy  of  the  resulting  draft  system  segment 
specifications  for  formal  review. 

The  number  of  people  involved  in  preparing  the  coordination 
copies  of  the  draft  system  segment  specifications  should  be  kept  to  a 
minimum.  Above  all,  never  ask  50  or  so  different  experts  to  each  prepare 
a  paragraph  for  one  of  the  50  or  so  different  subject  or  functional  areas  in 
the  specification,  expecting  to  staple  the  paragraphs  together  to  obtain  the 
draft  specification.  That  process  never  can  produce  a  consistent  and 
technically  valid  specification.  Always  start  with  a  good  draft  baseline 
generated  by  a  few  individuals.  When  the  draft  specification  is  ready, 
have  the  50  or  so  different  experts  on  the  coordination  list  review  it  and 
prepare  comments.  Note  that  it  is  impossible  to  provide  valid  comment  on 
single  paragraphs  extracted  from  the  draft  specification.  Everyone  in¬ 
volved  with  the  coordination  and  review  should  have  the  entire  specifi¬ 
cation,  even  if  they  are  expected  to  review  and  comment  on  only  a  single 
paragraph.  In  fact,  for  a  good  review,  each  expert  needs  to  have  available 
or  be  familiar  with  all  of  the  system  segment  specifications,  the  system 
specification,  and  perhaps  the  top-level  program  documents  such  as  the 
PBD,  the  PMD,  the  ADM,  and  the  MNS. 
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3.  SPACE  SYSTEM  SPECMCATION  REQUIREMENTS 


This  section  discusses  the  addition  of  the  program-peculiar 
requirements  to  the  model  specification  boilerplate  in  order  to  prepare  a 
space  system  specification  for  a  specific  program.  The  steps  are  straight¬ 
forward.  Simply  start  with  a  copy  of  the  Model  Space  System  Specification 
(Appendix  A),  and  then  check  each  item  with  the  program  requirements 
and  with  the  following  subsection  entries.  Unless  otherwise  indicated,  the 
paragraph  numbers  referenced  in  the  following  subsections  refer  to  those 
of  Appendix  A.  At  each  step,  the  program-peculiar  requirements  also  need 
to  be  added  to  or  merged  with  the  boilerplate  requirements  in  the  Model 
specification.  The  contents,  organization,  and  boilerplate  material  shown  in 
Appendix  A  should  be  changed  whenever  alteration  of  the  specification 
content  is  required  to  meet  the  needs  of  a  particular  system.  Nevertheless, 
it  is  recommended  practice  to  comply  with  the  boilerplate,  and  the  other 
suggestions  contained  herein,  unless  there  are  good  reasons  for  changes. 

For  the  convenience  of  those  who  might  worry  about  exact  compli¬ 
ance  with  MIL-STD-490A  and  Data  Item  Description  DI-CMAN-80008A, 
notes  are  included  with  the  text  of  the  following  subsections  to  indicate 
any  inconsistencies  in  DI-CMAN-80008A  or  MIL-STD-490A  and  how  they 
are  resolved.  In  addition,  notes  are  included  with  the  text  of  the  following 
subsections  to  indicate  where  additions  to  the  format  have  been  made  to 
accommodate  what  would  otherwise  be  missing  space  system  require¬ 
ments.  In  accordance  with  accepted  convention,  adding  paragraphs  and 
requirements  to  the  format  is  entirely  acceptable,  as  long  as  the  paragraph 
titles  and  numbers  specified  in  DI-CMAN-80008A  are  not  changed.  In 
other  words,  the  detailed  format  requirements  included  in  this  guide  are  in 
exact  compliance  with  DI-CMAN-80008A  and  the  general  requirements  of 
MIL-STD-490A.  This  means  that  there  is  no  need  for  the  specification 
preparer  to  be  confused  by  reading  DI-CMAN-80008A  or  MIL-STD-490A. 
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The  specification  preparer  should  add  the  program-peculiar 
requirements  to  the  model  specification  boilerplate  (Appendix  A),  and 
comply  with  the  instructions  provided  in  this  guidebook. 

3.1  TITLE  PAGE 

The  title  page  of  the  system  specification  shall  contain  the  applic¬ 
able  information  as  indicated  by  the  title  page  of  the  Model  specification 
(see  Appendix  A).  Note  that  although  there  may  be  approval  and 
authentication  signatures  on  the  document,  the  version  referenced  in  the 
contract  is  what  guides  the  contractor. 

3.2  TABLE  OF  CONTENTS 

The  system  specification  shall  contain  a  table  of  contents  as  indi- 
ated  in  Appendix  A.  Because  the  format  and  paragraphing  should  be  the 
same  for  all  space  system  specifications,  the  major  changes  in  a  table  of 
contents  for  a  particular  system  specification  would  be  in  the  page  num¬ 
bers  and  in  identifying  any  added  subparagraphs.  For  system  specifi¬ 
cations  that  are  printed  on  only  one  side  of  the  paper,  the  table  of  contents 
would  start  on  page  ii  (the  title  page  is  page  i,  but  is  always  unmarked). 

For  system  specifications  that  are  printed  on  both  sides  of  the  paper,  the 
back  of  the  title  page  would  be  page  ii  and  the  table  of  contents  would 
start  on  page  iii.  If  the  table  of  contents  ends  on  an  odd-numbered  page,  a 
blank  page  would  be  added  so  that  Section  1  would  start  on  a  right-hand 
page  (i.e.,  an  odd-numbered  page). 

3.3  SECTION  1.  SCOPE 

As  shown  in  Appendix  A,  the  first  section,  SCOPE,  starts  on  Page  1 
of  the  specification. 

Note  that  SECTION  1,  SCOPE  does  not  contain  design,  construction,  or  quality 
assurance  requirements,  only  brief  statements  that  expand  on  the  specification  title  to 
provide  identification  and  very  general  descriptive  information  pertinent  to  the  overall 
system.  Words  such  as  "shalf  or  “wiir  should  not  be  used  in  this  section. 
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3.3.1 


The  material  to  be  included  in  this  subsection  should  be  brief  and 
should  use  wording  similar  to  that  in  Appendix  A.  The  approved  identi¬ 
fication  number  and  title  of  the  system  should  be  stated.  If  an  abbrevia¬ 
tion  or  acronym  for  the  system  is  used,  it  should  also  be  stated. 

3.3.2  Subsection  1 .2.  SYSTEM  OVERVIEW 

The  material  to  be  included  in  this  subsection  should  consist  of  a 
clear,  concise  abstract  in  one  paragraph  of  the  system  mission  or  purpose. 

It  should  include  a  description  of  how  the  system  functions  and  interfaces 
with  other  external  systems. 

3.3.3  Subsection  1 .3.  DOCUMENT  OVERVIEW 

The  material  to  be  included  in  this  subsection  should  be  a  concise 
statement  of  the  content  and  intended  application  of  the  specification. 

3.3.4  Subsection  1,4.  SYSTEM  CLASSIFICATIONS 

In  many  large  systems,  the  requirements  for  the  final  system  can 
be  considerably  different  than  the  requirements  for  its  initial  configura¬ 
tion.  In  those  cases,  it  is  important  to  have  a  means  to  label  and  to  differ¬ 
entiate  between  requirements  applicable  to  the  configuration  for  the  initial 
operational  capability  and  those  applicable  to  succeeding  baseline  configu¬ 
rations.  The  names  of  the  various  baseline  configurations  or  classifications 
of  systems  should  be  established  in  this  paragraph.  A  brief  description  of 
the  mission  or  functional  differences  of  each  may  also  be  included;  how¬ 
ever,  if  the  descriptions  of  the  mission,  function,  usage,  or  purpose  of  each 
baseline  configuration  are  extensive,  they  should  be  stated  in  appropriate 
paragraphs  in  Section  6.  Of  course,  the  quantitative  requirements  associ¬ 
ated  with  each  baseline  configuration  would  be  stated  in  appropriate  para¬ 
graphs  in  Sections  3,  4,  and  5  of  the  Model  specification,  not  in  this  sub¬ 
section.  However,  a  statement  generally  is  added  that  all  requirements 
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stated  for  a  particular  baseline  configuration  (starting  with  the  initial 
operational  capability  baseline)  also  would  be  applicable  to  succeeding 
baseline  configurations,  unless  stated  otherwise. 

Note  that  Subsection  1 .4,  "Classification,"  should  be  deleted  if  only  one  system  baseline 
configuration  or  system  classification  category  is  covered  by  the  specification.  Although 
DI-CMAN-80008A  does  not  require  a  Subsection  1 .4,  "Classification,"  the  general 
requirements  of  MIL-STD-490A  do  require  it,  so  it  has  been  included  in  this  guidebook. 

One  alternative  to  this  paragraph  is  to  write  the  system  specification  for  the  initial 
operational  capability  only,  and  at  some  later  time  write  another  system  specification  for 
each  succeeding  baseline  configuration,  in  general,  a  smooth  transition  is  always  required 
from  the  initial  operational  capability  baseline  configuration  to  each  succeeding  baseline 
configuration.  For  that  reason,  the  requirements  for  the  different  baseline  configurations 
of  the  space  system  are  best  covered  in  the  same  specification  by  assigning  different 
classification  names  that  can  be  referenced.  The  Model  specification  presents  a  typical 
set  of  space  system  classifications  that  could  be  followed  to  avoid  any  confusion  or 
problems. 

3.4  SECTION  2.  APPLICABLK  DOgjMENTS 

As  shown  in  Appendix  A,  government  documents  are  listed  in 
Subsection  2.1  in  numerical  order  under  each  of  the  subheadings  shown. 
Nongovernment  documents  are  listed  in  Subsection  2.2.  Nongovernment 
documents  are  those  issued  by  no  government  organization  and  include 
documents  issued  by  technical  associations,  technical  societies,  commercial 
organizations,  and  contractors. 

The  words,  subheadings,  and  format  should  be  followed  with  the 
understanding  that  subheadings  will  be  omitted  if  they  do  not  contain 
applicable  documents.  A  parenthetical  source  statement  should  follow 
each  group  of  related  publications  indicating  the  address  of  the  source  of 
the  document  so  that  copies  may  be  obtained  directly  from  the  source. 

All  and  only  those  documents  identified  and  referred  to  in  Sections 
3,  4,  and  5  of  the  specification,  or  in  mandatory  compliance  appendices,  are 
listed  in  Section  2  of  the  specification.  However,  if  detailed  drawings  arc 
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referenced,  it  is  necessary  to  list  only  the  applicable  assembly  drawing  in 
Section  2,  as  long  as  the  assembly  drawing  itself  lists  the  detailed 
drawings. 

Note  that  a  specific  issue,  revision  letter,  and  the  date  of  issue  are 
given  for  each  of  the  referenced  documents.  The  revision  letters,  amend¬ 
ments,  notices,  and  effective  dates  shown  for  the  documents  listed  in  the 
Appendix  may  not  be  current;  so  they  would  require  updating  to  the  date 
of  issue  for  each  particular  specification.  Note  also  that  amendments  to 
military  specifications  supersede  earlier  amendments,  so  only  the  most 
recent  amendment  would  be  listed.  Notices,  however,  are  accumulative; 
only  those  notices  to  be  made  applicable  would  be  listed.  For  example,  if 
all  three  notices  were  applicable,  they  would  be  listed  as  Notices  "1" 
through  "3"  with  the  date  being  that  for  Notice  ”3."  Note  too  that  the 
preferred  method  of  stating  the  date  of  issue  for  each  document  is  day, 
month,  and  year.  The  day  would  be  given  in  two  digits,  the  month  in  three 
capital  letters,  and  the  year  in  two  digits.  If  a  different  date  format  is 
used,  it  should  be  used  consistently  for  all  of  the  documents  listed.  As  the 
acquisition  process  moves  forward,  many  of  the  specific  documents  refer¬ 
enced  may  be  amended,  revised,  or  superseded.  Just  because  a  referenced 
document  may  nave  been  updated  does  not  mean  that  the  revision  should 
be  referenced.  The  actual  updating  of  the  date  of  issue  for  each  of  the 
references  in  the  specification,  however,  must  be  considered  and  controlled 
by  the  program  office  in  the  same  manner  as  any  other  change  in  the 
specification. 

It  mujL  be  understood  that  the  whole  of  a  referenced  document  is 
not  made  applicable  by  its  inclusion  in  Section  2.  The  extent  of  applic¬ 
ability  is  only  that  which  is  clearly  defined,  and  specifically  indicated,  at 
the  place  it  is  referenced.  The  documents  listed  in  Section  2  of  Appendix  A 
are  those  that  are  reference  already  in  the  boilerplate  requirements.  As 
other  requirements  are  addeu  during  the  preparation  of  a  particular 
system  specification,  other  documents  may  be  referenced;  they  would  also 
be  added  in  Section  2. 
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Government  regulatory  documents,  such  as  directives,  regulations, 
manuals,  pamphlets,  and  policies,  usually  are  not  cited  for  compliance  in  a 
specification.  These  documents  generally  are  intended  for  internal  use  by 
government  organizations  only  and  are  not  intended  for  contractor  use. 
Also,  contractor  internal  specifications  or  documents  generally  are  not 
cited  in  a  system  specification.  Contractor  documents  typically  are  for 
internal  contractor  use  only  and  usually  are  not  so  general  as  to  be  directly 
applicable  or  transferable  to  a  different  contractor.  For  a  system,  usually 
several  different  contractors  are  involved,  so  documents  from  one  contrac¬ 
tor  could  be  misinterpreted  by  the  other  contractors.  Also,  contractor 
documents  are  not  readily  available  to  reviewing  organizations  or  to  the 
other  contractors  that  may  be  involved. 

Military  standards  or  other  DoD  standardization  documents  that 
address  or  include  nonproduct  or  management  requirements  never  should 
be  referenced  in  a  specification.  DoD  Directive  5000.1 9L,  Vol.  II,  Acquisi¬ 
tion  Management  Systems  and  Data  Requirement  Control  List,  provides  a 
complete  list  of  the  nonproduct  DoD  standardization  documents  that  should 
not  be  referenced  in  a  specification. 

Note  that  there  are  very  minor  differences  in  the  introductory  words  in  SECTION  2, 
APPLICABLE  DOCUMENTS,  between  this  guidebook  and  DI-CMAN-80008A  (Appendix  I 
of  MIL-STD-490A).  This  guidebook  addresses  all  order  of  precedence  issues  in 
Subsection  3.8  rather  than  some  in  Section  2  and  some  in  Subsection  3.8. 

3.5  SECTION  3.  SYSTEM  REQUIREMENTS 

As  shown  in  Appendix  A,  the  system  requirements  are  stated  in 
subsections  of  Section  3.  The  requirements  should  be  stated  in  terms  of 
the  performance,  reliability,  design  constraints,  functional  interfaces,  and 
so  forth  that  are  necessary  to  assure  a  practical  and  reasonable  develop¬ 
ment  effort.  The  requirements  should  clearly  describe  the  space  system 
and  should  include  any  unique  space  requirements  such  as  those  for 
manufacturing  process  control  of  critical  items.  Note  that  the  major 
elements  of  the  space  system  may  include  ground  equipment  as  well  as 
space  equipment.  Requirements  that  are  applicable  only  to  some  of  the 
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elements  should  not  be  stated  in  ways  that  would  make  those  require¬ 
ments  applicable  to  the  entire  system.  Functional  statements  of  the 
requirements  should  predominate  in  system  specifications  with  fabrication 
details  specified  only  to  assure  matching  interfaces  with  existing  elements. 
As  the  acquisition  progresses,  the  TBSs  and  TBDs  would  be  determined; 
those  requirements  would  be  incorporated  in  the  specification  and,  if 
appropriate,  in  lower-tier  specifications.  The  major  effort  in  the  initial 
phases  of  a  program  is  in  the  allocation  of  the  requirements  to  lower  levels 
of  assembly  and  the  preparation  of  specifications  for  the  system  segments 
and,  if  applicable,  for  lower-tier  prime  configuration  items  or  critical 
configuration  items. 

Referencing  military,  federal,  and  DoD-adopted  industry  specifica¬ 
tions  and  standards  is  the  approved  method  for  establishing  requirements 
that  are  adequately  set  forth  in  the  referenced  documents.  Before  refer¬ 
encing  any  document,  be  sure  to  read  the  specific  issue  of  the  referenced 
document  to  assure  the  applicability  of  the  requirements.  Tailoring  of  the 
references  should  be  accomplished  to  limit  the  extent  of  applicability  of 
the  requirements  such  as  illustrated  in  the  following  examples: 

a.  The  design  of  electronic  components  shall  be  in  accordance 
with  DOD-E~8983  would  incorporate  only  the  design  require¬ 
ments  of  DOD-E-8983  for  all  electronic  components  covered  by 
the  specification  (both  ground  and  space).  The  quality  assur¬ 
ance  provisions  would  not  be  made  applicable  by  such  a 
reference. 

b.  The  design  of  the  receiver  X  shall  be  in  accordance  with  DOD-E- 
8983  would  incorporate  only  the  design  requirements  of  DOD- 
E-8983  for  receiver  X,  but  not  for  any  other  possible  receivers 
or  applications  in  the  system  being  specified. 

c.  Electronic  components  for  space  vehicle  applications  shall  be  in 
accordance  with  DOD-E-8983  makes  all  requirements  (design 
and  quality  assurance)  in  DOD-E-8983  applicable  to  the 
electronic  components  to  be  used  in  space  vehicles  covered  by 
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the  specification.  Requirements  in  DOD-E-8983  would  not  be 
made  applicable  to  ground  components  or  to  aircraft 
components  by  such  a  reference. 

As  a  general  rule,  program-peculiar  specifications  external  to  the 
system  being  specified  should  not  be  referenced  except  to  identify  an 
interface.  Instead,  the  applicable  requirements  should  be  extracted  and 
incorporated  in  their  entirety.  This  is  particularly  true  of  requirements 
stated  in  specifications  that  are  viewed  as  higher-tier  specifications  or 
stated  in  specifications  prepared  by  different  government  agencies. 
Sometimes  a  reference  is  made  to  a  higher-tier  specification  in  the  belief 
that  such  a  reference  will  ensure  that  the  specified  item  will  be  required  to 
comply  with  all  of  the  applicable  requirements  in  the  higher-tier 
specification.  That  is  not  the  case,  because  the  requirements  in  the  higher- 
tier  specification  are  allocated  among  its  subtier  specifications.  The 
applicable  allocation  must  be  stated  in  each  of  the  subtier  specifications  to 
be  clear.  In  other  words,  a  reference  to  requirements  in  a  higher-tier 
specification  usually  is  not  clear,  because  the  proper  allocation  of  the 
higher-tier  requirements  is  unknown  by  contractors  working  at  a  lower 
tier  and  could  be  interpreted  differently  by  each  contractor  or  individual 
involved.  In  the  case  of  a  reference  to  requirements  in  a  specification 
prepared  by  a  different  government  agency,  experience  shows  that  the 
actual  hardware  and  the  requirements  stated  in  the  referenced  specifica¬ 
tion  may  differ,  and  this  may  place  an  unfair  burden  on  contractors  that 
are  directed  to  comply  with  both.  The  practice  of  extracting  requirements 
and  incorporating  them  in  the  applicable  specifications  rather  than  refer¬ 
encing  them  also  avoids  the  possibility  of  two  documents  each  referencing 
the  other,  and  each  document  stating  that  it  takes  precedence  over  the 
other  document.  These  problems  need  to  be  solved,  but  words  in  the 
specification  may  not  be  enough.  The  words  in  a  specification  cannot 
achieve  a  resolution  of  unknown  problems  that  require  SPO  action  to 
resolve,  nor  can  they  initiate  integrating  contractor  verification  tasks  to 
have  the  contractor  solve  the  problems,  since  a  task  can  be  initiated  only 
by  the  contract  SOW  (not  by  the  specification). 
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All  requirements  in  the  specification  should  be  stated  as  product- 
oriented  technical  requirements  for  the  system  being  specified.  Product- 
oriented  requirements  are  of  a  form  such  as  The  item  shall...,  or  The  test 
shall....  This  is  in  contrast  to  nonproduct  or  management  requirements  that 
are  of  a  farm  such  as  The  contractor  shall....  or  The  delivered  data  shall  .... 
For  example,  management  requirements  for  configuration  control,  work 
breakdown  structure,  safety  program,  quality  assurance,  reliability,  design 
reviews,  audits,  parts  control,  cost  reporting,  and  scheduling  would  be 
included  in  the  SOW  or  other  contract  provisions,  if  applicable,  but  they 
never  would  be  included  as  requirements  in  the  specifications.  Military 
standards  or  other  DoD  standardization  documents  that  address  or  include 
nonproduct  or  management  requirements  therefore  would  never  be  refer¬ 
enced  in  the  specification.  In  fact,  DoD  Directive  5000. 19L,  Vol  II,  Acqui¬ 
sition  Management  Systems  and  Data  Requirements  Control  List,  provides  a 
complete  list  of  the  nonproduct  DoD  standardization  documents  that  should 
not  be  referenced  in  a  specification.  The  list  includes  MIL-STD-490A,  MIL- 
STD-483A,  DOD-STD-2167A,  and  thousands  of  others.  Applicable  product- 
oriented  requirements  that  happen  to  be  included  in  nonproduct  DoD 
standardization  documents  usually  would  be  extracted  and  incorporated 
directly  in  the  specification,  rather  than  being  incorporated  by  reference. 

Of  course,  there  may  be  exceptions,  but  they  should  be  minimized. 

3.5.1  Subsection  3.1.  DEFINITION 

The  intent  of  the  material  included  in  this  subsection  and  subtier 
paragraphs  is  to  clearly  define  the  system  that  is  being  specified.  As  with 
any  definition,  the  intent  is  not  to  state  detailed  "shall"  requirements  but 
simply  to  describe  the  system  and  to  identify  its  major  physical  elements, 
its  functional  areas,  and  its  functional  and  physical  interfaces.  Depending 
upon  the  amount  of  system  engineering  that  may  have  been  completed 
and  the  complexity  of  the  system  being  specified,  the  definition  subpara¬ 
graphs  may  include  block  diagrams:  functional  diagrams;  logic  diagrams; 
schematic  diagrams;  specification  trees;  pertinent  organizational,  opera¬ 
tional,  and  logistic  concepts;  identification  of  major  system  segments;  and 
any  other  pertinent  descriptive  material. 
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These  definition  paragraphs  are  particularly  important  in  a  space 
system  specification.  In  the  initial  draft  of  the  specification.  Subsection 
3.1,  System  Definition,  may  have  most  of  the  text,  because  defining  the 
system  being  specified  is  always  the  first  step  in  preparing  a  space  system 
specification.  As  the  trade  studies,  analyses,  and  system  development 
progress,  additional  requirements  can  be  stated.  Eventually,  the  subtier 
elements  of  the  system  can  be  identified  to  provide  the  framework  of 
standard  terminology  to  be  used.  By  that  means,  all  participants  can 
recognize  common  items,  procedures,  schedules,  costs,  interfaces,  or  other 
common  elements  of  the  system  and  of  the  program.  Although  the  pri¬ 
mary  focus  in  these  paragraphs  is  on  the  description  of  the  space  system, 
including  the  identification  of  subtier  elements  of  the  system,  the  system 
interfaces  with  the  rest  of  the  world  also  may  be  identified.  How-ever, 
details  of  these  external  interfaces  should  be  included  in  Paragraph  3.2.3 
of  the  specification,  not  in  the  definition. 

By  including  the  definition  in  the  requirements  section,  contractors 
and  others  using  the  specification  can  recognize  the  intent  to  assure  com¬ 
pliance  with  the  space  system  description  given.  Although  requirements 
may  include  definitions,  note  that  definitions  are  not  an  appropriate  place 
to  include  detailed  performance,  design,  construction,  or  test  requirements. 
This  subsection  and  its  subparagraphs  are  definitions  that  are  intended  to 
be  descriptions  of  the  system  to  be  fulfilled  by  the  detailed  design,  as 
opposed  to  stating  "shall"  requirements  or  specifying  a  precise  set  of 
verifiable  performance  requirements.  All  the  detailed  requirements  are 
stated  in  subsequent  subsections  of  the  specification. 

As  shown  in  Appendix  A,  Subsection  3.1,  Definition,  may  be  only  a 
heading  (title)  with  text  in  subtier  paragraphs.  If  text  is  included  with  the 
header,  it  should  be  very  brief,  and  most  of  the  required  text  should  be 
within  the  subtier  paragraphs.  The  subtier  paragraphs  include  lists  that 
define  the  terminology  used  in  subsequent  subsections  of  the  specification. 
These  lists  are  for  the  convenience  of  those  using  the  specification  and  are 
incorporated  into  the  specification  to  the  extent  the  information  is  avail¬ 
able.  For  example,  the  subtier  elements  of  the  system,  such  as  the  system 
segments  or  prime  configuration  items,  may  not  be  identified  until  after 
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the  initial  trade  studies  have  been  completed.  Of  course,  the  lists  shown  in 
Appendix  A  are  typical  and  should  be  changed  to  conform  to  the  particular 
system  being  specified. 

Note  that  Subsection  3.1  in  DI-CMAN-80008A  does  not  require  any  lists  or  subtier 
paragraphs.  On  the  other  hand,  this  guidebook  has  added  a  required  set  of  subtier 
paragraphs.  They  provide  an  organizational  framework  and  check  lists  of  the  definition 
material  for  the  convenience  of  those  using  the  specification. 

Paragraph  3.1.1,  System  Description,  is  included  to  provide  a  brief 
statement  of  the  purpose  or  major  functions  of  the  system  and  to  identify 
other  systems  with  which  it  interfaces. 

Paragraph  3.1.2,  System  Segments,  is  included  to  identify  the 
system  segments  of  the  system.  This  is  a  list  of  the  system  segments  that 
may  be  known  at  the  time  the  space  system  specification  is  prepared. 

Paragraph  3.1.3,  Specification  Tree,  should  incorporate  the  system 
specification  tree  when  the  system  segments  of  the  system  and  at  least 
some  of  the  subtier  prime  configuration  items  or  other  subtier  elements  of 
the  system  segments  have  been  identified.  A  specification  tree  is  a  con¬ 
figuration  item  (Cl)  oriented  diagram  or  chart  that  shows  the  allocated  CIs 
that  make  up  the  item  being  specified.  The  specifications  which  identify 
each  subitem  would  be  shown  on  the  tree.  Other  specifications  that  serve 
to  identify  external  interfaces,  including  the  government-contractor  inter¬ 
faces,  also  may  be  shown.  The  applicable  portions  of  the  specification  tree 
for  the  entire  program  should  be  included,  if  they  are  available,  to  assist  in 
the  identification  of  the  system  and  interfaces.  In  any  case,  the  space  sys¬ 
tem  specification  tree  would  be  incorporated  to  identify  the  system  seg¬ 
ments  and  any  subtier  CIs  that  may  be  known  at  the  time  the  specification 
is  prepared.  When  the  specification  trees  are  depicted  in  a  separate  docu¬ 
ment  or  on  a  drawing  whose  size  prevents  incorporation  into  the  specifi¬ 
cation,  they  would  be  referenced  by  document  or  drawing  number. 

Paragraph  3.1.4,  Top-Level  System  Functions,  usually  is  only  a 
heading  (title)  with  text  in  subparagraphs. 
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A  system  function  is  a  statement  of  a  capability  that  the  system 
must  possess.  The  ultimate  system  function  expressed  in  the  Mission  Need 
Statement  commonly  is  decomposed  into  subtier  functions  illustrated  on  a 
master  flow  diagram  in  a  functional  analysis.  The  system  must  be  capable 
of  performing  or  satisfying  all  of  the  system  functions  identified  for  it  in 
one  or  more  prescribed  sequence(s)  in  order  to  satisfy  the  system  function 
expressed  in  the  Mission  Need  Statement.  A  functional  flow  diagram 
defines  functions  that  must  be  satisfied  and  the  required  sequences  for 
doing  so. 

For  each  block  on  the  master  flow  diagram,  one  or  more  functional 
requirements  statement(s)  are  written  that  are  then  allocated  (assigned)  to 
the  lower-tier  elements.  This  iterative  process  of  decomposing  the  Mission 
Need  Statement  into  lower-tier  functions  and  allocating  them  to  system 
elements  is  called  functional  analysis.  It  is  a  method  for  decomposing  the 
system  need  into  lower-tier  elements  that  subsequently  will  be  designed, 
fabricated,  tested  to  prescribed  requirements,  and  produced  to  satisfy  the 
stated  need.  The  two  products  of  this  process  are  the  architecture  ele¬ 
ments  of  the  system  to  which  the  functional  requirements  have  been  allo¬ 
cated  and  the  precursors  of  some  of  the  performance  requirements  for 
those  elements. 

Paragraph  3. 1.4.1,  Top-Level  System  Functional  Relationships, 
should  incorporate  the  top-level  master  flow  diagram  (functional  flow 
diagram).  If  a  top-level  functional  flow  diagram  for  the  program  is  devel¬ 
oped,  it  should  also  be  incorporated  into  this  paragraph.  The  program- 
level  diagram  provides  the  framework  for  describing  the  system  being 
specified  and  can  be  used  to  identify  interfaces  with  other  systems.  It  is 
the  basis  for  an  expansion  of  the  applicable  program-level  functions  to  the 
various  systems  associated  with  the  program. 

When  available,  layout  drawings  or  other  graphic  portrayals  which 
establish  the  general  relationship  of  functional  areas  and  the  major  ele¬ 
ments  of  the  system  may  be  included. 
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Paragraph  3. 1.4.2,  Description  of  System  Functions,  provides  an 
expanded  description  of  the  system  from  that  given  in  Paragraph  3.1.1.  A 
separate  subparagraph  should  be  used  to  address  each  of  the  top-level 
system  functions  identifying  in  Paragraph  3. 1.4.1.  Each  subparagraph 
would  contains  a  description  of  the  top-level  functions  and  their  relation¬ 
ships  to  each  of  the  operational  states  and  modes  identified  in  Paragraph 
3.1.5. 

Paragraph  3. 1.4. 3,  Missions,  is  included  to  provide  a  description  of 
the  operational  missions  that  could  affect  the  system  design. 

Paragraph  3. 1.4.4,  Threat,  is  included  to  identify  potential  threats 
to  the  system  that  should  be  considered  in  the  design  so  that  the  system 
performance  would-  not  be  jeopardized  if  the  threat  conditions  material¬ 
ized.  For  space  elements,  the  threat  might  include  nuclear  attack,  pellet 
attack,  laser  attack,  electronic  jamming,  all  of  the  above,  or  any  combina¬ 
tion.  For  ground  elements,  potential  threats  might  include  sabotage,  elec¬ 
tronic  jamming,  conventional  weapons  attack,  nuclear  attack,  and  so  forth. 
The  correct  entry  for  a  specific  system  would  be  provided  by  the  SSD 
Directorate  of  Intelligence.  Just  as  for  any  other  definition,  the  threat 
description  may  be  prepared  as  a  separate  document  and  referenced  in 
this  paragraph.  Also,  as  for  other  requirements,  the  quantitative  threat 
environments  should  be  stated  or  referenced  in  other  applicable  para¬ 
graphs  of  the  specification,  such  as  Paragraphs  3.2.2  or  3.2.6,  but  not  in  the 
definition. 

Note  that  D1-CMAN-80008A  says  that  the  mission  and  the  threat  should  be  addressed  in 
Section  6,  Notes,  which  is  not  a  compliant  section  of  the  specification.  Believing  that  the 
system  should  be  designed  to  meet  the  mission  and  to  operate  in  (or  survive)  the  threat 
requirements,  this  guidebook  requires  both  the  mission  and  the  threat  to  be  stated  here, 
i.e.,  in  Section  3,  Requirements. 

Paragraph  3.1.5,  System  States  and  Modes,  identifies  each  of  the 
operational  states  and  modes.  Once  the  system  architecture  elements 
derived  through  functional  analysis  are  known,  they  may  be  thought  of  as 
existing  in  and  transitioning  between  various  states  while  accomplishing 
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the  system  functions,  where  a  state  is  a  condition  of  a  system  or  system 
element.  System  states  may  be  identified  and  organized  into  state  tran¬ 
sition  diagrams,  where  circles  represent  the  states  and  arrowheaded  lines 
connecting  the  circles  represent  possible  transitions  between  states.  The 
analyst  refines  performance  requirements  derived  from  the  functional 
analysis  activity  and  allocated  to  the  elements  covered  by  the  state  dia¬ 
gram  into  more  precise,  quantified  performance  requirements  statements. 
Paragraph  3.1.5  provides  a  single  place  where  these  state  definitions  may 
be  captured.  States  may  include  prelaunch,  launch,  operational,  mainte¬ 
nance,  recovery,  and  others  that  could  be  appropriate  to  a  particular  sys¬ 
tem.  Within  each  state,  the  system  may  have  various  substates  or  modes, 
such  as:  (a)  surveillance,  (b)  threat  evaluation,  (c)  target  designation  and 
acquisition,  (d)  weapon  deployment,  and  (e)  data  reduction.  Modes  may 
include  various  configurations,  power  levels,  or  other  differences  that  may 
occur  during  one  of  the  states  that  require  special  design  attention.  It  is 
recognized  that  the  operational  states  and  modes  can  be  identified  and 
incorporated  into  the  specification  only  when  the  information  becomes 
available;  however,  many  performance  parameters  are  associated  with 
particular  states  and  modes,  so  it  is  helpful  to  list  them  all  in  one  place. 

Paragraph  3.1.6,  Operational  and  Organizational  Concepts,  usually  is 
included  in  a  system  specification  to  provide  operational  information  that 
could  help  define  the  system  and  that  could  affect  the  design.  This  may 
include: 

a.  The  basic  performance  parameters  upon  which  the  using 
activities  can  base  tactics  which  utilize  the  capabilities  of  the 
system  and  which  should  be  recognized  in  the  design. 

b.  Description  of  the  mission  in  terms  of  relationships  to  other 
items  of  the  system  or  to  other  systems. 

c.  Anticipated  deployment  of  the  system  equipment,  both  geo¬ 
graphically  and  organizationally,  such  as  the  number  of 
operational  vehicles,  number  of  ground  support  installations, 
and  their  operating  locations. 
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Note  that  the  model  specification  provides  general  words  for  a 
space  system  in  which  the  space  vehicle  is  launched  using  either  the  STS  or 
is  launched  using  an  expendable  launch  vehicle.  The  requirements  should, 
of  course,  be  changed  to  reflect  the  actual  operational  concept.  In  addition, 
any  organizational  concepts  that  could  affect  the  design  should  be  included 
in  added  paragraphs. 

3.5.2  Subsection  3.2.  CHARACTERISTICS 

This  subsection  generally  is  only  a  heading  (title)  with  text  in 
subtier  paragraphs.  The  requirements  and  constraints  stated  are  those 
that  may  be  applicable  to  the  system  as  a  whole  or  to  more  than  one 
system  segment.  The  requirements  stated  in  this  subsection  and  in  the 
subsequent  subsections  of  Section  3  are  those  that  were  alluded  to  in  the 
definition  and  descriptions  stated  in  the  paragraphs  of  3.1.  In  other  words, 
requirements  were  identified  in  Paragraph  3.1  only  to  help  define  the 
system,  but  the  actual  detailed  requirements  for  the  system  including 
interface  details  are  stated  in  this  and  subsequent  subsections.  This 
characteristics  subsection  therefore  is  intended  to  state  clearly  and  ii. 
quantitative  terms  the  pertinent  performance  requirements  and  physical 
characteristics  of  the  system.  Requirements  that  are  known  to  be  applic¬ 
able  only  to  a  single  system  segment  or  to  a  single  prime  Cl,  such  as  the 
space  vehicle,  should  be  stated  in  the  appropriate  paragraph  in  Subsection 
3.7  and  not  in  this  subsection. 

Paragraph  3.2.1,  Performance  Characteristics,  generally  is  only  a 
heading  (title)  with  text  in  subparagraphs.  The  content  of  this  paragraph 
or  of  the  subparagraphs  should  included  a  description  of  the  static  and 
dynamic  performance  requirements  for  the  system,  to  the  extent  possible 
at  the  time  the  system  specification  is  prepared.  This  paragraph  or  the 
subparagraphs  should  state  the  general  and  detailed  system  performance 
requirements,  i.e.,  what  is  expected  of  the  system,  including  both  the  range 
of  values  and  tolerances  for  each  mode  of  each  system  state.  This  para¬ 
graph  or  subparagraphs  shall  specify  the  performance  requirements  of  the 
system  and  provide  sufficient  guidance  to  form  the  basis  for  technical 
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features  and  development.  As  a  general  guide,  include  such  considerations 
as: 

a.  Dynamic  actions  or  changes  that  occur  (e.g.,  rates,  velocities, 
movements,  and  noise  levels). 

b.  Quantitative  criteria  covering  endurance  capabilities  of  the 
equipment  required  to  meet  the  user  needs  under  stipulated 
environmental  and  other  conditions,  including  minimum  total 
life  expectancy.  Indicate  required  mission  duration  and 
planned  utilization  rate. 

c.  Performance  requirements  for  the  operational  modes  and 
states. 

d.  Security  criteria. 

The  combined  performance  of  the  entire  system,  or  at  least  that  of 
two  or  more  of  the  system  segments,  is  addressed  in  this  paragraph  and 
the  subparagraphs.  The  performance  of  a  single  system  segment  or  of  an 
individual  Cl  would  be  addressed  in  Subsection  3.7  of  the  system  specifi¬ 
cation  (see  Appendix  A,  3.7).  The  specification  generally  includes  the  sub- 
paragraphs  shown.  Other  subparagraphs  for  other  performance  charac¬ 
teristics  may  be  added  in  this  subsection,  depending  upon  the  system. 

Note  that  there  is  a  conflict  in  DI-CMAN-80008A  between  the  required  content  of  Subsection 
3.7  and  the  required  level  of  detail  including  performance  requirements  for  subtier  elements  in 
this  Paragraph  3.2.1  (and  subparagraphs).  Instructions  in  DI-CMAN-80008A  for  Subsection 
3.7,  and  the  general  requirements  of  MIL-STD-490A,  say  to  include  all  requirements  identified 
with  individual  subtier  elements  in  Subsection  3.7.  This  guidebook  resolves  this  conflict  by 
following  the  general  Paragraph  3.2.1  structure  required  by  DI-CMAN-80008A  but  suggests 
that  all  subtler  requirements  be  put  in  Subsection  3.7  instead  of  in  subparagraphs  of  3.2.1 . 
There  also  is  another  question  as  to  the  interpretation  of  DI-CMAN-80008A  for  this 
Paragraph  3.2.1  and  its  subparagraphs.  The  instructions  in  DI-CMAN-80008A  say  to  include, 
in  quantitative  detail,  the  performance  requirements  for  each  capability  oi  the  system,  in  each 
mode,  of  each  state.  Each  caps^ility  is  not  defined;  however,  they  are  required  to  be  identified 
by  name  and  a  project-unique  identifier.  Each  capc^ility  might  be  each  top-level  function  or  it 
might  mean  each  prime  item.  In  either  case,  this  seems  to  be  a  subtler  level  of  detail  that 
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generally  is  not  available  at  the  time  the  system  specification  is  prepared.  Putting  whatever 
subtler  performance  requirements  that  are  available  in  Subsection  3.7  instead  of  in 
subparagraphs  of  3.2.1  is  a  good  compromise  for  resolving  these  problems  with  DI-CMAN- 
80008A,  and  it  is  the  course  implemented. 

Paragraph  3. 2. 1.1,  Performance  Requirements  for  Each  System 
State,  generally  is  only  a  heading  (title)  with  text  in  subparagraphs. 

Subparagraph  3.2.1.1.x  (beginning  with  3. 2. 1.1.1),  Performance 
Requirements  for  Each  System  State,  is  included  to  establish  a  set  of  sub- 
paragraphs  for  performance  requirements  for  each  state  of  the  system 
identified  or  defined  (see  Paragraph  3.1.5).  A  separate  subparagraph 
should  be  used  for  each  state  of  the  system.  In  each  subparagraph,  the 
static  and  dynamic  performance  requirements  for  each  capability  of  the 
system,  in  each  mode,  for  that  state  of  the  system  may  be  stated  to  the 
extent  possible  at  the  time  the  system  specification  is  prepared. 

Paragraph  3. 2. 1.2,  Endurance,  states  the  quantitative  criteria 
covering  endurance  capabilities  of  the  system  required  to  meet  user  needs 
under  stipulated  environmental  and  other  conditions,  including  minimum 
total  life  expectancy.  The  required  mission  duration  and  planned  utiliza¬ 
tion  rate  in  the  various  modes  should  be  indicated.  The  endurance 
requirements  in  Appendix  A  are  typical  and  should  be  changed  to  the 
times  and  requirements  of  the  specific  system. 

Paragraph  3.2. 1.3,  Other,  is  shown  to  highlight  the  fact  that  other 
performance  areas  can  be  addressed.  Any  essential  aspects  of  system 
performance  which  cannot  be  located  more  appropriately  under  another 
heading  in  this  outline  shall  be  stated  here. 

Paragraph  3.2.2,  System  Capability  Relationships,  generally  is  only 
a  heading  (title)  with  text  in  subparagraphs. 

Paragraph  3.2.2. 1,  Reference  Timelines,  is  where  typical  or  baseline 
functional  and  performance  timelines  would  be  stated  so  that  the  same 
timelines  could  be  used  in  designing  the  various  items  within  the  system. 
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Paragraph  3. 2. 2.2,  Description,  is  where  the  system  timelines 
would  be  described  in  words,  or  other  aspects  of  the  interrelationships  of 
the  system  capability  would  be  described. 

Paragraph  3.2.3,  External  Interface  Requirements,  may  be  only  a 
heading  (title)  with  text  in  separate  subparagraphs  for  each  external 
system  with  which  the  system  interfaces. 

Paragraph  3.2.3.x  (beginning  with  3.2.3. 1),  Description  of  External 
Interface  with  System  x,  is  where  the  external  interfaces  of  the  on-orbit 
space  system  with  elements  of  System  x  are  identified  and  detailed 
quantitative  interface  requirements  are  stated.  The  text  of  each  paragraph 
or  subparagraph  should  be  organized  to  describe  in  quantitative  terms  the 
interfaces,  including  the  purpose  of  each  interface  and  its  relationship  with 
each  of  the  modes  in  each  of  the  states  of  the  system.  Quantitative 
hardware-to-hardware  interface  requirements  may  include  items  such  as 
interface  dimensions,  tolerances,  input/output  voltages,  loads,  speeds,  or 
communications  protocol.  Quantitative  hardware-to-software  interface 
requirements  may  include  items  such  as  interface  bits  per  second,  word 
length,  message  formats,  serial  versus  parallel,  priority  rules,  or  protocols. 
Quantitative  software-to-software  interface  requirements  may  include 
items  such  as  interface  data  format,  communication  protocols,  or  frequency 
of  transfer. 

These  external  interface  descriptions  may  involve  references  to 
other  system  specifications  or  to  documents  prepared  by  other  agencies.  It 
is  important  to  recognize  the  uncontrolled  nature  of  these  external  inter¬ 
face  references.  For  example,  a  DoD  space  system  specification  may 
describe  an  interface  by  referencing  an  STS  specification  issued  by  NASA. 
That  reference,  however,  does  not  assure  that  the  actual  interface  will  be 
as  stated  or  that  it  will  not  be  changed  by  NASA  at  some  later  time. 

In  the  early  phases  of  a  system  acquisition,  the  referencing  of 
higher-level  specifications  or  external  documents  is  the  only  reasonable 
course  to  follow  in  describing  the  interfaces.  As  the  acquisition  progresses. 
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an  effort  should  be  made  to  eliminate  these  external  uncontrolled  refer¬ 
ences.  This  can  be  accomplished  by  the  preparation  and  joint  approval  of 
interface  control  documents.  The  interface  control  documents  then  could 
be  referenced  in  the  specification,  or  they  could  be  the  basis  for  the  direct 
incorporation  of  the  definitized  interface  requirements.  Eventually, 
detailed  Cl  specifications  would  be  prepared  for  the  actual  procurement  of 
the  various  system  elements.  These  Cl  specifications  should  be  standalone 
documents  and  should  not  reference  higher-level  specifications  or  extern¬ 
ally  controlled  documents.  This  practice  of  extracting  the  interface 
requirements  and  incorporating  them  in  the  applicable  specifications 
rather  than  referencing  them  avoids  the  possibility  of  two  documents  each 
referencing  the  other  and  each  document  stating  that  it  takes  precedence 
over  the  other  document.  Of  course,  extracting  the  interface  data  is  a 
necessary  step  in  any  case  before  production  drawings  can  be  made  or 
computer  software  produced.  Extracting  the  interface  requirements  and 
incorporating  them  in  the  applicable  specifications  makes  them  readily 
available. 

Paragraph  3.2.4,  Physical  Characteristics,  generally  is  only  a  head¬ 
ing  (title)  with  text  in  separate  subparagraphs.  Physical  characteristics 
include: 

a.  Weight  limits,  center-of-gravity  constraints,  and  moments  of 
inertia  constraints  for  elements  of  the  system. 

b.  Dimensional  and  volume  limitations,  crew  space,  operator 
station  layout,  ingress,  egress,  and  access  for  maintenance. 

c.  Requirements  for  tiedowns,  pallets,  packaging,  and  containers 
for  transport  and  storage. 

d.  Durability  factors  to  indicate  degree  of  ruggedness. 

e.  Vulnerability  factors,  including  consideration  of  atomic, 
chemical,  biological  and  radiological  operations,  electromagnetic 
radiation,  fire,  and  impact. 
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f.  Health  and  safety  criteria,  including  consideration  of  adverse 
explosive,  mechanical,  and  biological  effects.  Included  in  these 
criteria  are  the  toxicological  effects  of  the  item  or  component 
thereof  on  the  user  and  the  adverse  effects  of  any  electro¬ 
magnetic  radiation  that  might  emanate  therefrom.  In  systems 
with  nuclear  warheads,  general  requirements  for  peacetime 
operations,  troop  safety  in  handling  and  firing,  and  any  other 
nuclear  considerations  shall  be  included. 

g.  Security  criteria. 

The  physical  characteristic  requirements  that  are  applicable  only 
to  a  single  system  segment  or  to  an  individual  Cl  usually  would  be 
addressed  in  the  appropriate  paragraphs  in  Subsection  3.7  and  not  in  this 
paragraph.  To  assure  completeness,  and  to  avoid  any  possible  oversight, 
reference  to  the  applicable  paragraphs  in  Subsection  3.7  should  be 
included  in  this  paragraph.  Subparagraphs,  in  addition  to  those  shown  in 
Appendix  A,  may  be  added,  depending  upon  the  system  requirements. 

Note  that  many  paragraphs  under  Subsection  3.2  and  other  subsections  in  DI-CMAN- 
80008A  address  subject  areas  in  which  various  types  of  equipment  would  be  expected  to 
have  quite  different  general  requirements.  For  example,  space  vehicle  equipment,  fixed 
ground  equipment,  mobile  ground  equipment,  shipboard  equipment,  aircraft  equipment,  and 
other  major  types  of  equipment  typically  have  quite  different  requirements  in  many  of  the 
areas  addressed  in  the  specification,  and  the  requirements  for  each  need  to  be  stated 
clearly.  In  those  cases  in  which  the  system  includes  various  types  of  equipment  with 
requirements  that  are  known  to  be  different,  subparagraphs  should  be  added  to  separate 
clearly  the  requirements  applicable  to  each  type  of  equipment.  For  the  convenience  of  those 
using  Appendix  A,  a  required  set  of  subtier  paragraphs  are  included  to  separate  general 
boilerplate  requirements  applicable  to  space  vehicle  equipment  from  those  applicable  to 
ground  equipment.  On  the  other  hand,  the  boilerplate  material  shown  in  Appendix  A,  should 
be  changed  if  changes  are  needed  to  specify  the  needs  of  a  particular  space  system. 

Paragraph  3.2.4. 1,  Protective  Coatings,  states  the  applicable 
protective  coating  requirements  to  assure  protection  from  corrosion, 
abrasion,  or  other  deleterious  action. 
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Paragraph  3.2.4,2,  Mass  and  Size  Properties,  generally  is  only  a 
heading  (title)  with  text  in  separate  subparagraphs  that  follow.  The 
subparagraphs  state  requirements  for  limiting  and  controlling  the  mass 
and  size  properties  of  the  system  elements.  This  includes  the  identification 
of  the  coordinate  systems  used  in  the  system  and  any  envelope  constraints 
imposed  on  the  system.  Usually,  general  mass  and  size  property  require¬ 
ments  are  stated  in  subparagraphs  for  space  elements  such  as  the  space 
vehicle,  the  space  vehicle  support  equipment  for  use  in  the  STS  Orbiter, 
and  for  the  payload.  In  other  subparagraphs,  general  mass  and  size  prop¬ 
erty  requirements  for  fixed  and  mobile  ground  equipment  usually  are 
stated  to  avoid  excessive  floor  loading,  to  avoid  excessive  road  loading,  or 
to  allow  transportability. 

Paragraph  3. 2. 4. 3,  Power,  generally  is  only  a  heading  (title)  with 
text  in  separate  subparagraphs  that  follow.  The  subparagraphs  state  the 
requirements  both  for  external  electrical  power  to  be  supplied  to  the 
various  elements  of  the  system  and  for  power  to  be  generated  by  the 
various  elements  of  the  system  and  supplied  to  other  items.  Care  should 
be  taken  to  distinguish  between  power  supplied  to,  and  power  being 
supplied  from,  each  of  the  system  items  during  each  of  the  operating 
modes  in  each  system  state. 

Paragraph  3. 2.4.4,  Survivability,  is  where  requirements  would  be 
stated  for  consideration  of  atomic,  chemical,  biological,  radiological,  fire, 
and  impact  vulnerability  and  survivability. 

Paragraph  3. 2. 4. 5,  Other,  is  shown  to  highlight  the  fact  that  other 
physical  characteristics  can  be  addressed. 

Paragraph  3.2.5,  System  Quality  Factors,  generally  is  only  a 
heading  (title)  with  text  in  separate  subparagraphs  that  follow. 

Note  that  Quality  Assurance  Provisions  are  stated  in  Section  4  of  the  specification, 
not  in  this  paragraph. 
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Paragraph  3.2.5. 1,  Reliability,  and  the  associated  subparagraphs, 
state  requirements  for  the  reliability  of  the  system  to  perform  within 
specified  limits  for  the  service  life  of  the  system.  Other  subparagraphs 
may  be  added  to  cover  areas  other  than  mean  time  between  failures 
(MTBF)  and  redundancy. 

Paragraph  3. 2.5. 1.1,  Mean  Time  Between  Failures,  is  where  MTBF 
requirements  are  stated  for  the  system.  The  boilerplate  in  the  model 
specification  is  typical  but  should  be  changed  to  reflect  actual  program 
requirements. 

Paragraph  3. 2. 5. 1.2,  Redundancy,  is  a  typical  general  statement  of 
redundancy  requirements  for  all  elements  of  a  space  system.  Specific 
requirements  may  be  added,  or  changes  to  the  boilerplate  may  be  made, 
based  upon  the  system  requirements. 

Paragraph  3.2.5. 1.3,  Space  Vehicle  Reliability,  is  a  general 
statement  of  reliability  requirements  for  space  vehicles. 

Paragraph  3.2.5. 1.4,  Failure  Tolerance  of  Payloads  Using  the  STS,  is 
a  general  statement  of  requirements  for  payloads  using  the  STS. 

Paragraph  3. 2.5. 1.4.1,  Critical  Hazards,  is  a  definition  and  general 
statement  of  requirements  for  critical  hazards. 

Paragraph  3. 2.5. 1.4.2,  Catastrophic  Hazards,  is  a  definition  and 
general  statement  of  requirements  for  catastrophic  hazards. 

Paragraph  3. 2.5. 1.5,  Ground  Equipment  Reliability,  is  a  general 
statement  of  reliability  requirements  for  ground  equipment. 

Paragraph  3. 2.5. 2,  Maintainability,  generally  is  only  a  heading 
(title)  with  text  in  separate  subparagraphs  that  follow.  The  subparagraphs 
should  specify  the  quantitative  maintainability  requirements  in  the 
planned  maintenance  and  support  environments.  The  requirements  may 
include  such  items  as: 


d:SSD-GB-4Aa:EDC-M  AC-#1 3 


54 


a.  Mean  and  maximum  down  time,  reaction  time,  turnaround 
time,  mean  and  maximum  times  to  repair,  and  mean  time 
between  maintenance  actions. 

b.  Maximum  effort  required  to  locate  and  fix  an  error. 

c.  Maintenance  man-hours  per  flying  hour,  maintenance  man¬ 
hours  per  specific  maintenance  action,  operational  ready  rate, 
maintenance  hours  per  operating  hour,  frequency  of 
preventative  maintenance. 

d.  Number  of  people  and  skill  levels,  variety  of  support 
equipment. 

e.  Maintenance  costs  per  operating  hour,  man-hours  per  overhaul. 

Note  that  contractor  maintenance  generally  is  applicable  to  space 
systems  and  that  the  same  maintainability  requirements  usually  are  not 
applicable  to  all  elements  of  the  system. 

Paragraph  3.2.5.2.1,  Maintainability  of  Space  Vehicle  Equipment, 
specifies  the  quantitative  maintainability  requirements  of  the  space 
vehicle  equipment.  Unless  maintenance  or  servicing  in  space  is  specifically 
stated  as  a  program  requirement,  space  vehicles  and  experiments  usually 
are  designed  so  as  to  not  require  any  scheduled  maintenance,  repair,  or 
servicing  during  their  service  life. 

Paragraph  3. 2. 5.2.2,  Maintainability  of  Ground  Equipment,  specifies 
the  quantitative  maintainability  requirements  of  the  ground  equipment. 

Paragraph  3. 2. 5. 3,  Availability,  may  include  availability  require¬ 
ments  for  on-orbit  operations,  for  launch  readiness,  and  for  recovery. 
Availability  is  the  degree  to  which  the  system  shall  be  in  an  operable  and 
committable  state  at  the  start  of  a  mission  in  which  the  mission  is  called 
for  at  an  unknown  or  random  point  in  time.  When  the  STS  is  used,  limita¬ 
tions  are  imposed,  particularly  during  the  prelaunch  and  launch  sequence, 
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on  access  or  availability  of  the  system  space  equipment  for  test  or  main¬ 
tenance  activities.  When  applicable,  these  limitations  should  be  stated  in 
this  paragraph  because  of  their  possible  impact  on  the  space  equipment 
design  and  on  the  design  and  location  requirem  nts  for  ground  support 
equipment. 

Paragraph  3. 2.5.4,  Additional  Quality  Factors,  shall  specify  system 
quality  requirements  not  defined  in  the  above  subparagraphs  (e.g.,  dur¬ 
ability,  integrity,  efficiency,  or  correctness  requirements  of  the  system). 

Paragraph  3.2.6,  Environmental  Conditions,  generally  is  only  a 
heading  (title)  with  text  in  separate  subparagraphs  that  follow.  The 
subparagraphs  that  follow  provide  for  statements  of  the  various  environ¬ 
mental  levels  for  the  system  during  the  various  operating  phases.  If 
environmental  levels  are  specified,  they  should  be  the  design  levels  that 
include  the  desired  margins  and  the  allowable  measuring  error.  Where 
various  levels  are  possible  during  a  system  state  or  mode,  the  environ¬ 
mental  levels  or  ranges  specified  may  be  a  composite  that  covers  the 
maximum  and  minimum  values.  If  the  use  of  composite  values  is  not 
appropriate,  a  further  subdivision  should  be  used  to  make  the  necessary 
distinction  in  design  levels  for  the  various  states,  modes,  configurations,  or 
categories.  If  the  environmental  conditions  applicable  to  each  of  the 
various  system  segments  are  different  from  each  other,  the  environmental 
conditions  could  be  addressed  in  the  appropriate  paragraphs  in  Subsection 
3.7  and  not  in  this  paragraph.  To  assure  completeness,  and  to  avoid  any 
possible  oversight,  references  to  the  applicable  paragraphs  of  Subsection 
3.7  should  be  included  in  that  case.  The  environments  should  include: 

a.  Natural  environment  (e.g.,  wind,  rain,  temperature,  geographic 
location). 

b.  Induced  environment  (e.g.,  motion,  shock,  noise,  electro¬ 
magnetic  radiation). 

c.  Environments  due  to  enemy  action  (e.g.,  overpressure,  explo¬ 
sions,  radiation). 
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Note  that  Paragraph  3.2.6  in  DI-CMAN-80008A  does  not  establish  an  organization  for 
subparagraphing.  In  those  cases  in  which  the  system  includes  various  types  of  equipment 
with  environmental  requirements  that  are  known  to  be  different,  subparagraphs  should  be 
added  to  separate  clearly  the  requirements  applicable  to  each  type  of  equipment.  For  the 
convenience  of  those  using  Appendix  A,  a  required  set  of  subtier  paragraphs  is  included  to 
clearly  separate  general  boilerplate  requirements  applicable  to  space  vehicle  equipment  from 
those  applicable  to  ground  equipment.  On  the  other  hand,  the  boilerplate  material  shown  in 
Appendix  A  should  be  changed  if  changes  are  needed  to  specify  the  needs  of  a  particular 
space  system. 

Paragraph  3.2.6. 1  Environmental  Design  Margins,  is  intended  to 
present  the  environmental  design  margins  for  all  system  items. 

Paragraph  3. 2. 6.2  Environmental  Conditions  for  Space  Equipment, 
is  intended  to  present  the  design  environmental  requirements  for  all  space 
equipment. 

Paragraph  3.2.6.2.1,  Launch  Environments,  is  intended  to  present 
the  design  environmental  requirements  for  all  system  items  that  undergo 
launch.  This  would  be  specified  as  the  STS  payload  environment  for  STS 
launches,  the  launch  environment  inside  the  nose  fairing  for  an  expendable 
booster  if  that  is  appropriate,  or  it  could  be  a  composite  of  both  launch 
modes  if  that  is  appropriate. 

Paragraph  3. 2.6. 2. 2,  On-orbit  Environments,  states  the  design 
environmental  requirements  for  orbiting  elements  of  the  space  system. 

This  could  include  separation  from  the  STS,  injection,  various  on-orbit 
modes,  and  recapture  by  the  STS  as  may  be  appropriate  for  the  particular 
program. 

Paragraph  3.2. 6. 2. 3,  Ground  Environments  for  Space  Equipment, 
specifies  the  ground  environment  requirements  prior  to  launch  and 
possibly  after  return  from  orbit.  If  any  of  the  handling,  transportation,  or 
other  ground  environments  for  any  of  the  orbiting  elements  exceed  the 
design  values  specified  for  launch  or  on  orbit,  then  those  ground  environ¬ 
ments  should  be  specified.  Either  added  environmental  protection  then 
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could  be  developed  for  ground  operations,  or  the  ground  environments 
would  be  considered  in  the  design  of  the  orbiting  elements. 

Paragraph  3.2. 6.2. 4,  Other  Environments  for  Space  Equipment,  is 
intended  to  specify  the  design  environmental  requirements  for  the  various 
space  elements  of  the  space  system  during  other  applicable  modes  not 
covered  by  launch,  on  orbit,  or  ground  handling,  such  as  reentry  or  crash. 

Paragraph  3.2. 6.3,  Environniental  Conditions  tor  Ground  Equip¬ 
ment,  is  intended  to  present  the  design  environmental  requirements  for  all 
space  system  ground  equipment. 

Paragraph  3. 2. 6.4,  Environmental  Conditions  for  Other  Equipment, 
is  intended  to  present  the  design  environmental  requirements  for  all  other 
types  of  space  system  equipment. 

Paragraph  3.2.7,  Transportability,  generally  is  only  a  heading  (title) 
with  text  in  separate  subparagraphs  that  follow.  The  subparagraphs 
should  specify  the  requirements  for  system  transportability.  Make  sure 
the  specified  requirements  are  consistent  with  the  ground  environmental 
provisions  specified  in  the  environment  paragraphs  of  the  system 
specification  (Paragraph  3.2.6).  In  addition,  all  system  elements  that,  due 
to  operational  or  functional  characteristics,  will  be  unsuitable  for  normal 
transportation  methods  shall  be  identified. 

Note  that  Paragraph  3.2.7  in  DI-CMAN-80008A  does  not  establish  an  organization  for 
subparagraphing.  For  the  convenience  of  those  using  Appendix  A,  a  required  set  of  subtier 
paragraphs  is  included  to  suggest  general  boilerplate  requirements  applicable  to  space 
vehicle  equipment  and  those  applicable  to  ground  equipment.  On  the  other  hand,  the  boiler¬ 
plate  material  shown  in  Appendix  A  should  be  changed  if  changes  are  needed  to  specify  the 
needs  of  a  particular  space  system. 

Paragraph  3.2.8,  Flexibility  and  Expansion,  shall  specify  areas  of 
growth  which  are  required  to  support  planned  system  flexibility  and 
expansion.  Note  that  some  requirements  stated  in  other  sections  of  the 
specification,  such  as  limit  loads  or  structural  margins  of  safety,  also  may 
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be  a  factor  in  some  aspects  of  the  syjtem  flexibility  and  expansion.  It  is 
not  the  intent  that  those  requirements  be  repeated  in  this  section  or 
moved  to  this  section.  Essentially,  this  subparagraph  specifies  features  and 
spare  capacity  requirements  of  specific  elements  of  the  system  which  are 
not  stated  elsewhere  in  the  specification  and  that  are  require  to  support 
flexibility  and  expansion  of  the  system. 

Note  that  there  is  an  apparent  conflict  between  the  requirements  of  Paragraph  3.2.8, 
Flexibility  and  Expansion,  in  DI-CMAl  ,-80008A  and  the  requirements  of  Paragraph  3.3.1 1  in 
DI-CMAN-80008A  titled  Computer  Resources  Reserve  Capacity.  Computer  resources 
reserve  capacity  is  essentially  a  system  flexibility  and  expansion  issue  that  is  best 
addressed  here  and  not  in  a  separate  Paragraph  3.3.1 1.  Paragraph  3.2.8  in  Dl-CMAN- 
80008A  does  not  establish  an  organization  for  subparagraphing.  However,  to  highlight  the 
inclusion  of  computer  resource  re.serves  as  a  system  flexibility  and  expansion  requirement. 
Subparagraphs  3.2.8.1 ,  Operational  Computer  Resource  Reserves,  3.2.8.2,  Nonoperational 
Computer  Resource  Reserves,  and  3.2.8.3,  Other  Flexibility  and  Expansion  Requirements, 
have  been  established  in  Appendix  A.  In  other  words,  the  requirements  for  a  Paragraph 
3.3.1 1  in  DI-CMAN-80008A  have  been  moved  to  Subparagraphs  3.2.8.1  and  3.2.8.2  in  this 
guide,  and  in  Appendix  A.  Care  should  be  taken  to  separate  the  reserves  requirements 
applicable  to  operational  computer  resources  (Subparagraph  3.2.8.1)  and  those  applicable  to 
nonoperational  computer  resources  (Subparagraphs  3.2.8.2)  such  as  for  test  equipment  or 
trainers.  Other  subparagraphs  of  3.2.8.3  should  be  established  as  appropriate  to  the 
system.  On  the  other  hand,  the  boilerplate  material  shown  in  Appendix  A  should  be  changed 
if  changes  are  needed  to  specify  the  needs  of  a  particular  space  system. 

Subparagraph  3.2.8. 1,  Operational  Computer  Resource  Reserves, 
addresses  one  of  the  primary  areas  involving  requirements  for  system 
flexibility  or  expansion.  The  key  to  assuring  adequate  performance  of  the 
space  system,  and  of  its  potential  to  grow,  is  to  assure  that  the  space 
system  functions  properly  under  the  delivered  worst  case  throughput 
conditions,  that  the  required  throughput  reserves  are  present  and  can  be 
utilized,  and  that  adequate  reserves  in  memory,  processing  time,  and 
channel  capacity  are  present.  The  Appendix  A  example  deals  with  both 
the  throughput  reserves  and  the  reserves  applicable  to  the  data  processing 
subsystem  components.  The  design  process,  as  it  evolves,  should  ensure 
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that  the  system-level  reserves  and  the  component  reserves  are  compat¬ 
ible.  Note  that,  in  general,  the  requirements  for  operational  computer 
resource  reserves  in  the  operational  space  elements  are  different  from  the 
operational  computer  resource  reserves  in  the  operational  ground 
elements,  so  separate  subparagraphs  were  established  for  each  area. 

Expansion  requirements  for  computer  resources  usually  take  the 
form  of  reserves  in  all  types  of  computer  memory,  processing  instruction 
time,  and  data  channel  capacity.  These  three  characteristics  of  computer 
resources  typically  combine  to  provide  a  space  system  capability  to 
throughput  the  data  processing  actions  of  the  space  system.  The  through¬ 
put  is  necessary  to  allow  the  overall  space  system  to  perform  in  accord¬ 
ance  with  its  system  specification.  To  ensure  that  the  delivered  data  pro¬ 
cessing  subsystem  has  both  sufficient  engineering  margin  to  meet  worst- 
case  throughput  needs  and  the  expansion  capability  necessary  to  provide 
flexibility  in  modifying  system  performance  subsequent  to  initial  delivery 
of  the  space  system,  reserve  throughput  requirements  also  must  be  speci¬ 
fied.  Each  space  system  is  unique  in  its  demands  on  its  data  processing 
function  due  both  to  what  the  overall  space  system  is  supposed  to  do  and 
to  what  is  chosen  to  be  the  space  system  design.  Because  the  details  of  the 
space  system  design  are  not  apparent  when  a  system  specification  is  first 
prepared,  a  worst-case  throughput  requirement  cannot  be  stated  exactly 
but  instead  must  be  derived  in  light  of  the  emerging  system  design.  How¬ 
ever,  the  data  processing  subsystem  design  that  eventually  emerges  com¬ 
prises  computer  hardware  and  software  that  in  and  of  themselves  must 
have  reserves  compatible  with  the  final  agreed-upon  throughput  reserve 
applicable  to  the  overall  space  system.  These  individual  data  processing 
subsystem  margins  should  be  specified.  The  Appendix  A  example  deals 
with  both  the  space  system  throughput  reserves  and  the  reserves 
applicable  to  the  data  processing  subsystem  components.  The  design 
process,  as  it  evolves,  should  assure  that  the  system-level  reserves  and  the 
component  reserves  are  compatible. 

The  key  to  adequate  performance  of  the  space  system,  and  of  its 
potential  to  grow,  is  to  establish  and  measure  that  the  space  system  func¬ 
tions  properly  under  the  delivered  worst-case  throughput  conditions;  that 
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the  required  throughput  reserves  are  present  and  can  be  utilized;  and  that 
the  reserves  in  memory,  processing  time,  and  channel  capacity  are  present. 
(Note  that  this  ensemble  of  related  requirements  must  be  verified  as  being 
delivered  by  a  composite  of  testing  and  analysis.  In  the  actual  develop¬ 
ment  of  the  space  system  defined  by  the  system  specification,  it  will  be 
necessary  to  develop  test  scenarios,  prepare  test  plans  and  procedures  and 
execute  the  tests,  and  plan  for  and  conduct  measurements  to  ascertain  that 
reserves  are  preserved  during  execution  of  the  worst-case  throughput 
situation,  both  in  system  throughput  and  in  component  reserves.  Subpara¬ 
graph  4.2. 2.2. 3.4  specifies  computer  resources  reserves  verification  tests.) 
As  noted  above,  the  data  processing  subsystem's  requirement  to  provide  a 
reserve  in  delivered  throughput  capability  can  impact  the  design  or  selec¬ 
tion  of  the  computer  resources  components  in  that  they  must  provide  com¬ 
patible  reserves  in  memory,  processing  time,  or  data  channel  capacity.  In 
the  general  case,  all  the  system  reserves  discussed  above  tend  to  be  con¬ 
strained,  under  normal  design  conditions,  to  be  compatible  with  the  design 
approach  selected  for  the  system.  System  extensions  conceivably  could  be 
specified  that  may  or  may  not  be  compatible  with  the  throughput  reserve 
design  approach.  In  this  case,  the  ability  to  employ  the  throughput 
reserve  may  not  be  achievable,  and  costly  redesign  may  be  required. 

Where  broad  flexibility  in  system  extension  is  anticipated,  careful  control 
over  the  selected  data  processing  subsystem  design  must  be  exercised. 

Subparagraph  3. 2. 8. 1.1,  Computer  Resource  Reserves  for  Oper¬ 
ational  Space  Elements,  addresses  requirements  in  operational  space 
elements  for  system  flexibility  or  expansion.  For  the  purposes  of  this 
specification,  the  data  processing  subsystems  of  the  operational  space 
elements  are  defined  to  comprise  all  computer  hardware,  software,  and 
firmware  in  the  space  vehicle(s),  including  all  interfacing  space  equipment 
and  payloads  except  government-furnished  equipment  (GFE)  payloads 
required  to  support  operational  missions.  The  typical  requirements  shown 
in  Appendix  A  should  be  changed  to  specify  the  needs  of  a  particular  space 
system.  In  general,  the  requirements  for  operational  computer  resource 
reserves  in  the  space  elements  are  different  from  the  computer  resource 
reserves  in  the  ground  elements. 
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Paragraph  3. 2. 8. 1.2,  Computer  Resource  Reserves  for  Operational 
Ground  Elements,  addresses  requirements  in  operational  ground  elements 
for  system  flexibility  or  expansion.  For  the  purposes  of  this  specification, 
the  operational  data  processing  subsystems  of  the  ground  elements  of  the 
space  system  are  defined  to  comprise  all  computer  hardware,  software, 
and  firmware  required  to  support  operational  missions  that  are  not  in 
space  elements.  The  typical  requirements  shown  in  Appendix  A  should  be 
changed  to  specify  the  needs  of  a  particular  space  system.  In  general,  the 
requirements  for  operational  computer  resource  reserves  in  the  ground 
elements  are  different  from  the  computer  resource  reserves  in  the  space 
elements. 

Subparagraph  3. 2. 8. 2,  Nonoperational  Computer  Resource  Reserves, 
addresses  another  of  the  primary  areas  involving  requirements  for  system 
flexibility  or  expansion.  Care  should  be  taken  to  define  nonoperational 
computer  resources  in  the  specification  (see  Paragraph  3.3.8).  Nonopera¬ 
tional  computer  resources  typically  are  included  in  nonspace  or  ground 
items  such  as  test  equipment  or  trainers,  where  the  flexibility  or  expansion 
requirements  could  be  quite  different  than  for  operational  computer 
resources. 

Subparagraph  3. 2. 8. 3,  Other  Flexibility  and  Expansion  Require¬ 
ments,  addresses  requirements  in  other  elements  of  the  system,  other  than 
computer  resource,  for  system  flexibility  or  expansion.  For  example,  if  the 
system  includes  electrical  power  generation  equipment,  or  fuel  storage 
tanks,  should  there  be  a  single  unit  or  a  number  of  parallel  units  with  the 
potential  to  add  additional  units?  Also,  what  surplus  capacity  should  be 
provided? 

Paragraph  3.2.9,  Portability,  shall  specify  requirements  for  porta¬ 
bility  which  are  applicable  to  system  equipment  and  software  to  permit 
employment,  deployment,  and  logistic  support.  In  Appendix  A  this  para¬ 
graph  is  marked  Not  applicable  because  the  portability  requirements  for 
most  space  systems  already  are  included  in  other  paragraphs  of  the  speci¬ 
fication.  The  portability  requirements  for  computer  resources  are  stated  in 
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Paragraph  3.3.11  and  subparagraphs,  and  in  Paragraph  3.3.7  and  subpara¬ 
graphs  for  transportation.  Of  course.  Appendix  A  should  be  changed  if 
changes  are  needed  to  specify  the  needs  of  a  particular  space  system. 

3.5.3  Subsection  3.3.  DESIGN  AND  CONSTRIJCTTON 

This  subsection  generally  is  only  a  heading  (title)  with  text  in 
separate  subtier  paragraphs.  The  intent  of  the  paragraphs  included  in  this 
subsection  is  to  specify  minimum  system  design  and  construction  stand¬ 
ards  which  have  general  applicability  to  system  equipment  and  are  applic¬ 
able  to  major  classes  of  equipment  (e.g.,  space  vehicle  equipment,  ground 
support  equipment,  etc.)  or  are  applicable  to  particular  design  standards. 
To  the  maximum  extent  possible,  these  requirements  shall  be  specified  by 
incorporation  of  references  to  the  established  military  standards  and 
specifications.  In  addition,  this  paragraph  shall  specify  criteria  for  the 
selection  and  imposition  of  federal,  military,  and  contractor  specifications 
and  standards.  Design  and  construction  requirements  and  constraints  that 
are  applicable  to  a  special  system  function  (as  might  be  defined  ultimately 
in  greater  detail  in  a  single  system  segment  or  to  a  single  Cl)  usually  would 
be  stated  in  the  appropriate  paragraphs  of  Subsection  3.7  and  not  in  this 
subsection.  In  that  case,  the  paragraphs  in  this  subsection  should  refer¬ 
ence  the  appropriate  paragraphs  in  Subsection  3.7  in  order  to  avoid  any 
possible  oversight. 

Paragraph  3.3.1,  Materials,  generally  is  only  a  heading  (title)  with 
text  in  separate  subtier  subparagraphs.  Subparagraph  3. 3. 1.1  in  DI-CMAN- 
80008A  is  the  only  subparagraph  established.  However,  other  subpara¬ 
graphs  are  to  be  added  to  specify  those  system-peculiar  requirements 
governing  use  of  materials,  parts,  and  processes  in  the  design  of  system 
equipment.  The  subparagraphs  shall  direct  attention  to  prevent  unneces¬ 
sary  use  of  strategic  or  critical  materials.  (A  strategic  and  critical  materials 
list  may  be  obtained  from  the  contracting  agency.)  In  addition,  any 
requirements  for  the  use  of  standard  and  commercial  parts  and  parts  for 
which  qualified  products  lists  have  been  established  shall  be  specified  in 
the  subparagraphs. 
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For  the  convenience  of  those  using  Appendix  A,  a  required  set  of 
other  subtier  subparagraphs  is  included  to  suggest  general  boilerplate 
requirements  applicable  to  space  vehicle  equipment  and  those  applicable 
to  ground  equipment.  On  the  other  hand,  the  boilerplate  material  shown  in 
Appendix  A  should  be  changed  if  changes  are  needed  to  specify  the  needs 
of  a  particular  space  system. 

Paragraph  3. 3. 1.1,  Toxic  Products  and  Formulations,  shall  specify 
requirements  for  the  control  of  toxic  products  or  formulations  to  be  used  in 
the  system  or  to  be  generated  by  the  system.  The  general  provisions  of  a 
government  contract  require  compliance  with  the  laws  of  the  land  that 
already  impose  many  controls  of  toxic  products  or  formulations.  This 
paragraph  needs  to  address  only  additional  controls  peculiar  to  the  system. 

Note  that  Paragraph  3.3.1. 1  in  DI-CMAN-80008A  is  the  only  subparagraph  established.  For 
the  convenience  of  those  using  Appendix  A,  a  required  set  of  other  subtier  paragraphs  is 
included  to  suggest  general  boilerplate  requirements  applicable  to  space  vehicle  equipment 
and  those  applicable  to  ground  equipment. 

Paragraph  3. 3. 1.2,  Materials,  Processes,  and  Parts  for  Space  Vehicle 
Equipment,  and  the  subparagraphs  that  follow  state  general  boilerplate 
requirements  for  the  space  vehicle.  Deletions  or  additions  should  be  made 
where  appropriate  to  satisfy  the  requirements  for  a  particular  system. 

Note  that  the  management  task  of  establishing  a  parts,  materials,  and 
processes  control  program  for  space  vehicle  equipment  is  not  included  in 
the  specification  but  would  be  stated  as  a  task  in  the  SOW  when  it  is  a 
formal  requi’^ement. 

Paragraph  3. 3. 1.3,  Materials,  Processes,  and  Parts  for  Ground 
Equipment,  and  the  subparagraphs  that  follow  state  general  boilerplate 
requirements  for  the  space  system  ground  equipment.  Deletions  or 
additions  should  be  made  where  appropriate  to  satisfy  the  requirements 
for  a  particular  system.  Note  that  the  management  task  of  establishing  a 
parts,  materials,  and  processes  control  program  for  ground  equipment  is 
not  included  in  the  specification  but  would  be  stated  as  a  task  in  the  SOW 
when  it  is  a  formal  requirement. 
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Paragraph  3.3.2,  Electromagnetic  Radiation,  states  the  general 
requirements  for  electromagnetic  compatibility  (EMC).  The  requirements 
in  the  paragraph  should  address  both  the  radiation  environment  in  which 
the  system  must  operate  as  well  as  that  which  the  system  is  permitted  to 
generate.  If  there  are  technical  TEMPEST  requirements  imposed  to  limit 
radiation  from  the  elements  of  the  system,  they  should  be  stated. 

Paragraph  3.3.3,  Nameplates  and  Product  Marking,  states  the 
general  boilerplate  product  marking  requirements  that  will  be  required  to 
identify  equipment  when  it  is  produced.  The  paragraph  shall  contain 
requirements  for  nameplates,  part  marking,  serial  and  lot  number  mark¬ 
ing,  software  media  marking,  and  other  identifying  markings  required  for 
the  system.  Reference  may  be  made  to  existing  standards  on  the  content 
and  application  of  markings.  Because  these  requirements  usually  are  more 
severe  in  space  systems  than  for  other  military  equipment,  and  they  may 
impact  other  design  and  construction  requirements,  it  is  appropriate  to 
include  detailed  requirements  in  the  system  specification. 

Note  that  in  Appendix  A,  all  software  media  marking  requirements  are  stated  in  the 
computer  resources  Paragraph  3.3.11  and  subparagraphs.  Of  course,  Appendix  A  should  be 
changed  if  changes  are  needed  to  specify  the  needs  of  a  particular  space  system. 

Paragraph  3.3.4,  Workmanship,  states  the  general  workmanship 
requirements  for  equipment  to  be  produced  during  system  development 
and  requirements  for  manufacture  by  production  techniques.  This 
includes  workmanship  requirements  for  development  models  or 
prototypes  to  be  produced  during  the  system  development. 

Paragraph  3.3.5,  Interchangeability,  specifies  the  requirements  for 
system  equipment  to  be  interchangeable  and  replaceable.  Entries  in  this 
paragraph,  or  subparagraphs,  are  for  the  purpose  of  establishing  a  condi¬ 
tion  for  design  and  not  to  define  the  conditions  of  interchangeability 
required  by  the  assignment  of  a  part  number. 

Paragraph  3.3.6,  Safety,  states  the  safety  design  requirements 
which  are  basic  to  the  design  of  the  system,  with  respect  to  equipment 
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characteristics,  methods  of  operation,  and  environmental  influences.  This 
paragraph  also  shall  specify  those  safety  design  requirements  which  pre¬ 
vent  personal  injury  and  equipment  degradation  without  degrading  opera¬ 
tional  capability  (e.g.,  restricting  the  use  of  dangerous  materials;  where 
possible,  classifying  explosives  for  purposes  of  shipping,  handling,  and 
storing;  abort/escape  provisions  from  enclosures;  gas  detection  and  warn¬ 
ing  devices;  grounding  of  electrical  system,  cleanliness,  and  decontamina¬ 
tion;  and  explosion  proofing). 

Safety-related  requirements  applicable  to  a  single  functional  area 
should  not  be  addressed  in  this  paragraph  but  should  be  stated  with  the 
requirements  for  the  functional  area.  For  example,  safety  requirements 
applicable  to  explosive  ordnance  should  be  addressed  in  Paragraph  3.3. 9. 6, 
Explosive  Ordnance,  and  safety  requirements  applicable  to  pressurized 
components  should  be  addressed  in  Paragraph  3. 3. 9. 4,  Pressurized  Compo¬ 
nents.  This  discipline  of  putting  together  all  requirements  for  a  product 
area  or  type  in  one  place  is  intended  to  assure  that  critical  requirements, 
including  safety,  are  not  overlooked  by  the  various  design,  manufacturing, 
and  quality  experts.  Similarly,  safety-related  requirements  applicable 
only  to  a  single  system  segment  or  to  a  single  subtier  Cl  usually  would  be 
addressed  in  the  appropriate  paragraph  in  Subsection  3.7  and  not  in  this 
paragraph.  Reference  to  the  applicable  paragraphs  in  Subsection  3.7  can 
be  included  in  this  paragraph  if  one  wants  to  assure  completeness. 

Note  that  the  management  task  of  establishing  a  safety  program 
based  upon  an  approved  safety  plan  is  not  included  in  the  specification.  If 

constraints  are  to  be  applied  to  the  management  of  a  contractor  safety 
program,  they  would  be  stated  as  tasks  in  the  SOW,  and  the  approval  of 
the  safety  plan  would  be  required  by  an  appropriate  entry  on  the  Contract 
Data  Requirements  List  (CDRL). 

Paragraph  3.3.7,  Human  Engineering,  states  the  general  boilerplate 
design  requirements  for  accommodating  man-equipment  interactions.  This 
paragraph  should  reference  applicable  documents  (e.g.,  MIL-STD-1472) 
and  also  specify  any  special  or  unique  requirements  such  as  any  con¬ 
straints  on  allocation  of  functions  to  personnel,  constraints  on  verbal 
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communications,  and  personnel-equipment  interactions.  This  paragraph 
shall  include  requirements  for  those  specific  areas,  stations,  or  equipment 
which  would  require  concentrated  human  engineering  attention  due  to  the 
sensitivity  of  the  operation  or  criticality  of  the  task;  i.e.,  those  areas  in 
which  the  effects  of  human  error  would  be  particularly  serious. 

Paragraph  3.3.8,  Nuclear  Control  Requirements,  states  the  general 
requirements  for  controlling  nuclear  material.  These  requirements  may 
induce  component  design,  in-flight  controls,  prevention  of  inadvertent 
detonation,  and  nuclear  safety  rules  that  are  applicable  to  design  or 
construction. 

Paragraph  3.3.9,  System  Security,  shall  specify  security  require¬ 
ments  that  are  basic  to  the  design  of  the  system  with  respect  to  the 
operational  environment  of  the  system.  This  subparagraph  also  shall 
specify  those  security  requirements  necessary  to  prevent  compromise  of 
sensitive  information  or  materials  that  are  applicable  to  design  or 
construction. 

Paragraph  3.3.10,  Government-Furnished  Property  Usage,  shall 
specify  any  GFE  to  be  incorporated  into  the  system  design.  In  addition, 
this  paragraph  shall  specify  any  government-furnished  information  (GFI) 
and  government-furnished  software  (GFS)  to  be  incorporated  into  the 
system.  This  list  shall  identify  the  government-furnished  property  by 
reference  to  its  nomenclature,  specification  number,  and/or  part  number. 
If  the  list  is  extensive,  it  may  be  included  as  an  appendix  or  in  a  separate 
document  which  then  would  be  referenced  in  this  paragraph.  The  lists  in 
the  model  specification  are  typical  and  should  be  changed  to  conform  to 
the  particular  system.  Specific  quantities,  including  spares,  should  be 
indicated. 

Note  thift  government  contracts  usually  contain  an  Attachment  which  lists  the  applicable 
GFE  including  the  availability  dates.  Care  should  be  taken  to  ensure  that  the  contract 
Attachment  and  the  specification  agree. 


6  7 


d:SSD-GB-4Aa;EDC-MAC-#l  3 


Paragraph  3.3.10,  Government-Furnished  Property  Usage,  is  the 
last  subparagraph  established  in  Subsection  3.3  by  DI-CMAN-80008A, 
since  the  requirements  for  a  Paragraph  3.3.11,  Computer  Resource  Reserve 
Capacity,  in  DI-CMAN-80008A  have  been  transferred  to  Paragraph  3.2. 8.1, 
Computer  Resource  Reserves,  in  this  guide,  and  in  Appendix  A. 

For  space  systems,  there  are  a  number  of  system  design  and  construction  requirement 
areas  that  are  not  addressed  clearly  by  the  required  paragraphs  of  Subsection  3.3  of  Dl- 
CMAN-80008A.  Paragraphs  therefore  have  been  added  starting  with  a  new  Paragraph 
3.3.1 1 ,  Computer  Resources,  in  Appendix  A.  This  new  paragraph  recognizes  that  there  are 
system-level  computer  resource  requirements  (other  than  reserve  capacity)  and  provides  a 
location  for  them.  Other  subtier  paragraphs  for  system  design  and  construction  require¬ 
ments  that  have  not  been  addressed  also  are  included  to  document  general  requirements 
applicable  to  space  vehicle  equipment  and  those  applicable  to  ground  equipment.  The 
boilerplate  material  shown  in  Appendix  A  should  be  changed  if  changes  are  needed  to 
specify  the  needs  of  a  particular  system. 

Paragraph  3.3.11,  Computer  Resources,  states  general  requirements 
applicable  to  computer  resources  to  be  developed  as  elements  of  the 
system  (other  than  reserve  capacity  which  is  addressed  in  Paragraph 
3.2.8. 1).  Computer  resources  include  all  computer  software  and  the  associ¬ 
ated  computational  equipment  included  within  the  system.  Computational 
equipment  is  the  equipment  that  is  capable  of  executing  symbolically 
expressed  instructions  as  well  as  all  of  the  associated  peripheral  devices. 
The  computational  equipment  and  the  associated  peripheral  equipment 
include  processing  units;  main  storage;  peripheral  data  storage;  special- 
purpose  computation  devices;  input/output  units  such  as  printers,  graphic 
displays,  and  video  display  devices;  and  other  associated  devices. 

This  paragraph,  and  the  associated  subparagraphs,  should  be 
prepared  with  the  understanding  that  the  specification  usually  is  written 
before  the  functional  requirements  are  allocated  to  specific  computers  or 
to  specific  computer  software.  Nevertheless,  past  experience  has  shown 
that  a  large  fraction  of  system  problems  and  system  life  cycle  costs 
eventually  will  be  attributed  to  the  computer  resources.  It  is  therefore 
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important  to  document  as  early  as  possible  the  known  technical  require¬ 
ments.  Of  course,  requirements  that  naturally  fall  in  categories  covered  by 
other  paragraphs  of  the  system  specification  should  be  stated  in  those 
paragraphs,  even  though  eventually  they  may  be  allocated  to  specific 
computer  resources.  Only  the  general  technical  requirements  having 
significant  impact  on  the  performance,  selection,  design,  sizing,  interfaces, 
or  scheduling  of  the  computer  resource  elements  should  be  stated  in  this 
and  the  associated  subparagraphs. 

In  stating  the  computer  resources  requirements  for  the  overall 
space  system,  often  it  is  necessary  to  categorize  the  computer  resources 
into  various  functional  areas  of  the  space  system.  This  is  because  the 
requirements  for  computer  resources  in  each  of  the  system  functional 
areas  may  not  be  identical.  In  Appendix  A,  computer  resources  are 
grouped  and  identified  as  those  that  functionally  support  operations,  those 
used  for  computer  software  maintenance,  those  embedded  in  test  equip¬ 
ment,  and  those  included  in  other  functional  areas  such  as  in  trainers.  Of 
course,  if  all  the  general  requirements  for  computer  resources  apply  to  all 
functional  areas,  it  is  not  necessary  to  distinguish  between  the  functional 
areas,  since  all  of  the  requirements  would  apply  fully  to  all  areas.  Appen¬ 
dix  A  indicates  how  the  general  requirements  typically  are  tailored  within 
each  of  the  functional  areas.  This  type  of  subdivision  of  the  system  com¬ 
puter  resources  should  be  used  to  avoid  overspecifying  computer  resour¬ 
ces  requirements  within  a  particular  system  functional  area.  More  than 
four  functional  area  categories  may  be  required  for  some  systems  and  less 
than  four  for  other  systems. 

Paragraph  3.3.11.1,  Operational  Computer  Resources,  states  any 
general  requirements  for  computer  resources  which  are  required  to 
support  functional  operations  during  one  or  more  phase(s)  or  mode(s)  of 
the  system  service  life.  The  operational  computer  resources  may  include 
on-line  and  off-line  data  processing,  communications,  display,  and  control 
functions.  The  operational  computer  resource  requirements  are  grouped 
by  subparagraphs  into  those  applicable  to  equipment,  computer  operating 
systems,  application  computer  software,  and  other  special  areas  such  as 
firmware.  Although  most  operational  computer  resources  in  space  systems 
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are  on  the  space  vehicles  or  on  the  ground,  they  also  may  be  on  other 
vehicles  such  as  on  launch  vehicles,  aircraft,  ships,  and  trucks.  Care  should 
be  taken  to  distinguish  differences  in  the  requirements  that  may  be 
applicable  to  the  different  vehicles. 

Paragraph  3.3.11.2,  Computer  Software  Maintenance  Resources, 
states  any  general  requirements  for  computer  software  maintenance 
resources  required  during  the  system  operational  service  life  to  develop 
and  test  changes  to  operational  computer  software.  These  resources  and 
facilities  often  are  the  same  as,  or  similar  to,  those  used  for  the  develop¬ 
ment  of  the  computer  software.  However,  it  is  not  appropriate  to  include 
requirements  for  computer  software  development  resources  or  facilities  in 
a  specification,  because  they  are  simply  development  tools  and  not  part  of 
the  system  being  specified.  Only  requirements  for  the  computer  software 
maintenance  resources  and  facilities  required  to  support  computer 
software  changes  during  the  operational  service  life  should  be  included  in 
the  specification.  These  requirements  include  those  applicable  to 
equipment,  computer  operating  systems,  application  computer  software, 
firmware,  data  archives,  and  maintenance  tools. 

Paragraph  3.3.11.3,  Computer  Resources  in  Test  Equipment,  states 
any  general  requirements  for  computer  resources  embedded  in  the  test 
equipment  that  will  be  required  to  support  the  maintenance,  repair,  and 
checkout  of  the  system  hardware  following  system  deployment. 

Paragraph  3.3.11.4,  Computer  Resources  in  Trainers,  states  any 
general  requirements  for  computer  resources  embedded  in  equipment 
used  for  the  training  of  system  operators.  Of  course,  if  there  is  no  training 
equipment  in  the  system,  then  this  paragraph  will  be  deleted.  If  there 
were  other  types  of  computer  resources  required  by  the  system,  other 
paragraphs  could  be  added  as  appropriate. 

Paragraph  3.3.12,  Space  Vehicle  Design  Requirements,  generally  is 
only  a  heading  (title)  with  text  in  separate  subparagraphs  that  follow.  The 
subparagraphs  address: 
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3.3.12.1  General  Structural  Design 

3.3.12.2  Strength  Requirements 

3.3.12.3  Stiffness  Requirements 

3.3.12.4  Structural  Factors  of  Safety 

3.3.12.5  Design  Load  Conditions 

3.3.12.6  Space  Vehicle  Fluid  Subsystems 

3.3.12.7  Moving  Mechanical  Assemblies 

3.3.12.8  Explosive  Ordnance 

3.3.12.9  Wiring  Harness 

3.3. 1 2. ’0  Electronic  Components 
3.3.12.11  Solar  Arrays 

Paragraph  3.3.13,  Operational  Ground  Equipment:  General  Design 
Requirements,  generally  is  only  a  heading  (title)  with  text  in  separate 
subparagraphs  that  follow.  The  subparagraphs  address: 

3.3.13.1  General  Structural  Design 

3.3.13.2  Strength  Requirements 

3.3.13.3  Stiffness  Requirements 

3.3.13.4  Structural  Factors  of  Safety 

3.3.13.5  Design  Load  Conditions 

3.3.13.6  Fluid  Subsystems 

3.3.13.7  Electronic  Components 

d;SSD-GB-4Aa:EDC-MAC-#13  7  1 


Paragraph  3.3.14,  Nonoperational  Ground  Equipment;  General 
Design  Requirements,  may  be  only  a  heading  (title)  with  text  in  separate 
subparagraphs  that  follow.  In  Appendix  A,  nonoperational  ground 
equipment  for  the  system  is  defined  in  this  paragraph.  Subparagraphs 
address  the  requirements  for  Embedded  Nonoperational  Elements  and 
Other  Nonoperational  Ground  Equipment  (Test  Equipment  and  Trainers). 

Paragraph  3.3.15,  General  Construction  Requirements,  may  be  only 
a  heading  (title)  with  text  in  separate  subparagraphs  that  follow. 

Paragraph  3.3.15.1,  Processes  and  Controls  for  Space  Vehicle 
Equipment,  states  the  general  requirements  for  manufacturing  processes 
and  controls  for  space  vehicle  equipment.  The  intent  of  the  subparagraphs 
is  to  clearly  impose  manufacturing  process  control  requirements  needed  to 
assure  the  achievement  of  the  high  levels  of  reliability  required  for  initial 
and  subsequent  production  of  the  critical  elements  of  the  space  system. 
These  process  control  requirements  are  particularly  applicable  whenever 
production  of  more  than  one  item  is  planned.  The  manufacture  of  addi¬ 
tional  space  system  items  usually  is  planned  with  interrupted  production, 
because  the  scheduled  need  dates  may  be  months  or  even  years  apart. 
Simply  screening  completed  items  is  not  an  adequate  method  of  assuring 
the  pedigree  of  critical  space  equipment.  Therefore,  the  requirement  is 
that  the  supplier  be  able  to  construct  any  additional  production  units  the 
same  way  and  with  the  same  quality  that  was  used  for  the  initial  produc¬ 
tion. 


Paragraph  3.3.15.2,  Processes  and  Controls  for  Ground  Equipment, 
states  the  general  requirements  for  manufacturing  processes  and  controls 
for  ground  equipment. 

3.5.4  Subsection  3.4.  DOCUMENTATION 

This  subsection  shall  specify  the  requirements  for  system  docu¬ 
mentation  such  as  specifications,  drawings,  technical  manuals,  test  plans 
and  procedures,  and  installation  instruction  data.  Note  that  only  docu¬ 
ments  or  data  listed  on  the  CDRL  are  deliverable.  The  requirements  stated 
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here  are  to  assure  that  the  contractors  have  visibility  for  the  designs,  pro¬ 
cedures,  and  specifications  by  which  all  processes,  operations,  inspections, 
and  tests  are  accomplished. 

3.5.5  Subsection  3.5.  LOGISTICS 

This  subsection  states  the  logistic  considerations  and  conditions 
that  apply  to  the  operational  requirements.  These  considerations  and 
conditions  may  include: 

a.  Maintenance 

b.  Transportation  modes 

c.  Supply-system  requirements 

d.  Impact  on  existing  facilities 

e.  Impact  on  existing  equipment 

The  focus  should  be  on  requirements  that  constrain  the  system 
design  and  impact  the  system  life  cycle  cost.  The  allocation  of  the 
program-level  logistic  requirements  to  the  system  and  to  lower-tier  levels 
generally  is  based  on  minimizing  the  program  and  system  life  cycle  cost. 
Even  including  the  possible  retrieval  of  space  vehicles  by  the  STS,  the 
maintenance  or  refurbishment  opportunities  for  space  equipment  are 
extremely  limited  when  compared  to  other  military  equipment.  In  addi¬ 
tion,  the  production  quantities  of  space  vehicles  totals  only  a  few  of  each 
type,  and,  for  this  and  other  valid  reasons,  the  use  of  standard  military 
parts  or  items  in  space  equipment  is  trivial.  These  factors  usually  mean 
that  requiring  contractor  logistic  support  for  the  service  life  of  the  space 
equipment  can  avoid  many  of  the  added  costs  associated  with  using 
military  personnel  for  logistic  support  and  the  military  logistic  supply 
system  for  spare  parts.  Unless  the  ground  equipment  associated  with  the 
system  is  to  be  located  in  the  front  lines  in  the  event  of  a  conflict,  life  cycle 
cost  considerations  usually  dictate  that  the  contractor  be  assigned  respon¬ 
sibility  for  all  logistic  support  for  the  service  life  of  the  space  system.  If 
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for  any  reason  the  space  system  design  should  be  based  on  other  than 
contractor  logistic  support,  it  is  important  to  provide  detailed  requirements 
in  the  maintenance,  supply,  and  facilities  subparagraphs.  Even  when 
contractor  logistics  support  is  planned,  there  may  be  requirements  that 
should  be  stated  in  the  subparagraphs  to  assist  the  design  personnel  in  the 
contractor  organization. 

Note  that  Subsection  3.5  in  DI-CMAN-80008A  does  not  establish  an  organization  for  subtier 
paragraphing.  For  the  convenience  of  those  using  Appendix  A,  a  suggested  set  of  subtier 
paragraphs  is  included.  The  boilerplate  material  shown  in  Appendix  A  should  be  changed  if 
changes  are  needed  to  specify  the  needs  of  a  particular  space  system. 

Paragraph  3.5.1,  Support  Concept,  shall  specify  the  support 
concept.  This  subparagraph  shall  include  the  following: 

a.  Use  of  multipurpose  test  equipment 

b.  Repair  versus  replacement  criteria 

c.  Organizational  levels  of  maintenance  such  as  the  extent  of 
maintenance  to  be  accomplished  at  specific  locations  such  as  at 
the  launch  site,  on  orbit,  at  the  landing  site,  at  operating  sites, 
at  the  depot  (if  one  is  to  be  used),  or  at  the  factory 

d.  Maintenance  cycles,  and  test,  repair,  and  refurbishment  time 
lines 

e.  Accessibility 

f.  Other  requirements  not  previously  mentioned  such  as  the  use 
of  module  versus  part  replacement 

Paragraph  3.5.2,  Support  Facilities,  usually  is  only  a  title  heading 
for  the  subparagraphs  that  follow.  Nevertheless,  one  could  address  the 
impact,  if  any,  of  the  system  on  existing  facilities  and  facility  equipment  or 
any  requirements  for  new  facilities  or  ancillary  equipment  to  support  the 
system  logistics.  The  facility  and  facility  equipment  requirements,  if  any, 
eventually  would  be  transferred  to  separate  facility  specifications  or  other 
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appropriate  documents  to  support  their  procurement.  Generally,  facility 
procurements  and  space  system  equipment  procurements  are  entirely 
separate  contracts,  and  separate  specifications  would  be  appropriate. 


Paragraph  3.5.2. 1,  Hardware  Support,  shall  specify  the  system 
requirements  for  hardware  support  facilities  and  equipment.  Quantitative 
requirements  shall  be  stated  for  usage  of  existing  facilities  and  equipment 
in  sufficient  detail  so  that  availability  may  be  verified.  Quantitative 
requirements  shall  be  stated  for  new  or  modified  facilities  and  equipment 
in  sufficient  detail  to  permit  planning  of  construction  or  procurement. 

Paragraph  3. 5. 2. 2,  computer  software  configuration  item  (CSCI) 
support,  shall  specify,  directly  or  by  reference,  the  facilities,  equipment, 
and  software  required  for  CSCI  support  during  the  system's  operational 
life.  The  Computer  Software  Maintenance  Resources  to  be  developed  as 
required  by  Paragraph  3.3.11.2  are  for  this  purpose,  so  they  should  be 
referenced.  (The  requirements  could  be  moved  to  this  paragraph  and 
omitted  from  Subsection  3.3;  however,  that  v'as  not  done.)  Note  that  the 
Computer  Software  Maintenance  Resources  to  be  developed  should  be 
equivalent  to  the  computer  resources  used  for  development  of  the  com¬ 
puter  software.  The  Computer  Software  Maintenance  Resources  are 
envisioned  as  becoming  a  government-furnished  facility  for  computer 
software  maintenance  during  the  operational  life  of  the  system,  whereas 
the  specific  computer  resources  used  for  development  might  not  be 
planned  for  delivery  to  the  government. 

Note  that  Paragraph  3.5.2.2  in  Appendix  A  simply  states  that  the  Computer  Software 
Maintenance  Resources  to  be  developed  as  required  by  Paragraph  3.3.1 1 .2  shall  be  used  for 
CSCI  support  during  the  system's  operational  life.  Care  should  be  taken  in  writing  the 
acquisition  contracts  to  assure  that  the  required  Computer  Software  Maintenance 
Resources  will  be  delivered  to  the  government,  or  that  other  suitable  arrangements  are 
made  for  CSCI  support  during  the  system’s  operational  life  (such  as  contractor 
maintenance  of  the  computer  software). 
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Paragraph  3.5.3,  Supply,  could  address  such  items  as: 

a.  Introduction  of  new  parts  or  items  into  the  supply  system. 

b.  Supply  or  re-supply  methods. 

c.  Distribution  and  location  of  item  stocks. 

d.  Special  storage  requirements  for  parts  or  items. 

3.5.6  Subsection  3,6.  PERSONNEL  AND  TRAINING 

This  subsection  generally  starts  with  a  title  heading  for  the 
paragraphs  that  follow.  For  space  systems  where  life  cycle  cost  is  a 
primary  consideration,  operators  and  maintenance  personnel  usually  are 
provided  by  the  system  contractors.  In  that  case,  personnel  and  training 
requirements  typically  would  be  determined  by  the  contractors  as  part  of 
the  design  tradeoff  studies.  For  some  systems,  there  may  be  a  hard 
stipulation  that  military  personnel  will  operate  or  maintain  the  system 
equipment.  In  that  case,  care  should  be  used  to  provide  the  detailed 
personnel  and  training  requirements  needed  by  the  system  designers. 

Paragraph  3.6.1,  Personnel,  should  address  the  personnel  require¬ 
ments  for  operators  and  for  maintenance  personnel  which  must  be  inte¬ 
grated  into  the  system  design.  These  requirements  shall  be  stated  in 
terms  of  numbers  plus  tolerance  and  shall  be  the  basis  for  contractor 
design  and  development  decisions.  Requirements  stated  in  this  paragraph 
shall  be  the  basis  for  determination  of  system  personnel  training,  training 
equipment,  and  training  facility  requirements.  Personnel  requirements 
shall  include,  but  not  be  limited  to: 

a.  Numbers  and  skills  of  support  personnel  for  each  operational 
deployment  mode  and  the  intended  duty  cycle,  both  normal 
and  emergency. 

b.  Skills  and  numbers  of  personnel  that  shall  be  allocated  to  the 
operation,  maintenance,  and  control  of  the  system. 
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When  military  personnel  are  to  be  used,  it  is  important  that  the 
required  number  of  personnel  at  each  of  the  available  skill  levels  be 
identified.  Care  should  be  taken  to  avoid  personnel  requirements  that  are 
too  lax,  because  they  can  impose  costly  constraints  on  the  equipment 
design  and  on  other  areas  of  the  program  such  as  requirements  for  spares. 
Care  also  should  be  taken  to  avoid  personnel  requirements  that  are  overly 
restrictive,  because  suitable  military  personnel  may  not  be  readily  avail¬ 
able.  For  contractor  operation  or  maintenance,  it  would  be  appropriate  to 
describe,  in  general  terms,  the  educational  background,  experience,  or 
other  qualifications  desirable  for  personnel  selected  to  be  trained  to 
operate  and  maintain  the  system. 

Paragraph  3.6.2,  Training,  should  address  training  requirements  to 
the  extent  they  are  known  and  to  the  extent  that  they  might  effect  the 
design  of  the  system.  This  could  include: 

a.  Contractor  and  government  responsibility  for  training  require¬ 
ments.  This  subparagraph  also  shall  specify  the  concept  of  how 
training  shall  be  accomplished  (e.g.,  school,  contractor  training). 

b.  Equipment  being  developed  that  will  be  required  tor  training 
purposes. 

c.  Training  devices  to  be  developed,  characteristics  of  the  training 
devices,  and  training  and  skills  to  be  developed  through  the 
use  of  training  devices. 

d.  Training  time  and  locations  available  for  a  training  program. 

e.  Source  material  and  training  aids  to  support  the  specified 
training. 

Note  that  Paragraph  3.6.2,  in  Appendix  A,  states  some  task-related  requirements  such  as 
training  times  and  locations;  but  remember  that  the  .soecification  cannot  be  used  to  buy 
services,  only  to  state  requirements  that  can  help  in  the  design  process  of  the  system  or  of 
the  training  equipment.  Care  should  be  taken  in  writing  the  acquisition  contracts  to  assure 
that  the  required  training  equipment  will  be  delivered  to  the  government,  and  that  other 
suitable  contractual  arrangements  are  made  for  contractor  training  service. 


d:SSD-GB-4Aa:EDC-MAC-#13 


77 


3.5.7  Subsection  3.7.  CHARACTERISTICS  OF  SUBORDINATE  ELEMENTS 


This  subsection  generally  starts  with  a  title  heading  for  the  para¬ 
graphs  that  follow.  Subtier  paragraphs  are  established  in  this  subsection 
to  provide  places  to  identify  and  describe  requirements  that  have  been 
allocated  from  the  system  requirements  to  a  system  segment  or  that 
describe  interfaces  among  the  system  segments.  These  requirements 
eventually  could  form  the  core  of  system  segment  specifications  or  prime 
item  specifications  that  would  be  developed  as  the  acquisition  progresses. 
However,  requirements  need  not  be  allocated  to  any  of  the  system  seg¬ 
ment  subtier  elements  in  order  to  prepare  a  system  specification.  All 
entries  and  subtier  paragraphs  in  Subsection  3.7  are  optional.  As  a  system 
acquisition  progresses,  system  requirements  will  be  allocated  to  Subtier 
Elements  (system  segments  or  prime  items).  The  allocated  requirements 
can  be  put  directly  into  the  system  segment  specifications  or  into  prime 
items  specifications  just  as  easily  as  in  Subsection  3.7.  When  system  seg¬ 
ment  or  prime  item  specifications  can  be  identified,  the  subtier  specifica¬ 
tions  should  be  referenced  in  these  subtier  paragraphs.  Referencing  the 
subtier  specifications  is  far  better  than  trying  to  repeat  the  details  directly 
in  these  subtier  paragraphs.  The  Model  specification  (Appendix  A)  should 
be  changed  if  changes  are  needed  to  specify  the  needs  of  a  particular  space 
system. 


Note  that  Subsection  3.7  in  DI-CMAN-80008A  states  that  subtier  paragraphs  shall  be 
established  to  identify  and  describe  each  segment  of  the  system.  DI-CMAN-80008A  also 
states  that  the  subparagraphs  shall  describe  the  relationships  between  the  segments  and  shall 
provide  the  following  information  for  the  segment: 

a.  State  the  purpose  of  the  segment. 
t  Provide  a  brief  description  of  the  segment, 
c.  Identify  the  system  capabilities  the  segment  performs. 

These  DI-CMAN-80008A  information  requirements  will  be  met  when  system  segment  or  prime 
item  specifications  have  been  prepared;  they  are  referenced  in  these  subtier  paragraphs.  As 
in  other  sections  of  the  system  specification,  requirements  cannot  be  included  if  they  do  not 
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exist,  such  as  is  the  case  at  the  start  of  a  new  system  acquisition.  For  the  convenience  of 
those  using  the  Model  Space  System  Specification  (Appendix  A),  suggested  subtier 
paragraphs  are  discussed  in  considerable  detail;  however,  it  is  entirely  acceptable  to  mark 
Subsection  3.7  or  any  subtier  paragraphs  TBS  or  Not  applicable  if  that  is  appropriate. 

Paragraph  3.7.1,  Requirements  Allocated  to  Subtier  Elements, 
generally  starts  with  a  title  heading  for  the  subparagraphs  that  follow.  A 
subparagraph  typically  would  be  established  to  address  each  of  the  system 
segments.  If  the  content  of  any  of  these  system  segment  paragraphs  or 
subparagraphs  is  extensive,  the  material  should  be  organized  similar  to  the 
planned  organization  of  a  system  segment  specification  that  would  be 
developed  for  the  segment  as  the  acquisition  progresses.  In  fact,  the 
requirements  in  these  paragraphs  may  be  stated  by  referencing  the 
applicable  system  segment  specifications  if  they  exist.  For  the  space 
system,  the  space  system  segment  requirements  may  be  so  extensive  that 
it  may  be  desirable  to  prepare  the  space  system  segment  specification  at 
the  same  time  the  space  system  specification  is  prepared.  In  that  case,  the 
space  system  segment  specification  would  be  referenced  in  its  paragraph. 
Requirements  of  the  other  system  segments  could  either  be  incorporated 
directly  in  their  appropriate  paragraphs  or  incorporated  by  referencing 
separate  specifications  prepared  for  them.  The  purpose  of  preparing 
separate  segment  specifications  at  the  same  time  the  space  system  specifi¬ 
cation  is  prepared  is  to  avoid  ambiguity  in  the  requirements.  The  use  of 
separate  system  segment  specifications  also  may  help  allocate  the  general 
requirements  among  ihe  various  elements  of  the  system.  The  detailed 
allocation  of  performance,  errors,  reliability,  and  other  requirements 
among  the  various  system  segments  and  CIs  should  be  the  subject  of  trade 
studies  to  be  conducted  during  the  concept  development  phase  by  either 
the  contractors,  the  government,  or  both.  If  no  requirements  have  been 
allocated  to  or  identified  with  a  particular  subtier  system  segment  at  the 
time  the  system  specification  is  being  prepared,  the  paragraph  for  that 
system  segment  may  be  omitted.  In  fact,  initial  system  specifications  may 
be  prepared  without  any  requirements  being  stated  in  any  paragraphs  or 
subparagraphs  in  Subsection  3.7. 
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Paragraph  3.7.2,  Internal  Interface  Requirements,  shall  be  divided 
into  the  following  subparagraphs  to  describe  the  internal  interfaces.  (To 
achieve  maximum  system  design  flexibility,  the  subparagraphs  below, 
which  specify  the  internal  interfaces  in  detailed  terms,  normally  are  com¬ 
pleted  by  the  contractor  rather  than  the  contracting  agency.  The  contrac¬ 
ting  agency  may  provide  this  information  when  necessary  to  meet  system 
needs.) 


Requirements  that  describe  interfaces  among  the  segments  are 
internal  interfaces  in  the  system  specification,  but  they  are  external 
interfaces  in  the  system  segment  specifications.  Interfaces  among  the 
segments  typically  are  documented  in  interface  control  documents  signed 
or  approved  by  the  system  segment  contractors.  If  interface  control 
documents  exist,  they  may  be  referenced  in  these  subtier  paragraphs; 
eventually  they  would  be  referenced  in  the  applicable  system  segment 
specifications  or  prime  items  specifications. 

Paragraph  3.7.2. 1,  Internal  Interfaces  Identification,  shall  identify 

all  interfaces  between  hardware  Cls  and  computer  software  CIs  in  this 
system.  This  subparagraph  may  reference  a  system  internal  interface 
diagram  to  identify  the  interfaces. 

Paragraph  3. 7. 2.2,  Internal  Hardware  CI-to-Hardware  Cl  Inter¬ 

faces,  shall  specify  by  name  and  number  all  hardware  CI-to-Hardware  Cl 
interfaces  within  the  system.  If  a  signal  is  transmitted  between  hardware 
CIs,  the  hardware  Cl  transmitting  the  signal  and  the  hardware  Cl  receiving 
the  signal  shall  be  specified.  In  addition,  where  required,  each  interface 
shall  be  specified  in  detailed  quantitative  terms  (e.g.,  input/ou^nut  volt¬ 
ages,  dimensions,  tolerances,  loads,  speeds). 

Paragraph  3. 7. 2. 3,  Internal  Hardware  Cl-to-Computer  Software  Cl 

Interfaces,  shall  specify  by  name  and  number  all  hardware  Cl-to-computer 
software  Cl  interfaces  within  the  system.  For  each  interface,  the  hardware 
Cl  or  computer  software  Cl  transmitting  the  signal  and  the  hardware  Cl  or 
computer  software  Cl  receiving  the  signal  shall  be  specified.  In  addition, 
where  required,  each  interface  shall  be  specified  in  detailed  quantitative 
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terms  (e.g.,  bits  per  second,  word  length,  message  format,  frequency  of 
messages,  priority  rules,  protocol). 

Paragraph  3. 7. 2.4,  Internal  Computer  Software  Cl-to-Computer 
Software  Cl  Interfaces,  shall  specify  by  name  and  number  all  computer 
software  Cl-to-computer  software  Cl  interfaces  within  the  system.  For 
each  interface,  the  computer  software  Cl  transmitting  the  data  and  the 
computer  software  Cl  receiving  the  data  shall  be  specified.  In  addition, 
where  required,  each  interface  shall  be  specified  in  detailed  quantitative 
terms  (e.g.,  data  format,  communication  protocol,  frequency  of  transfer). 

Paragraph  3.7.3,  Requirements  Traceability  Matrices,  is  an  optional 
paragraph  in  which  a  summary  matrix  can  be  referenced  that  correlates 
the  allocation  of  system  functions  first  to  the  system  segments  and  then, 
for  each  system  segment,  to  the  corresponding  subtier  Hardware  CI(s)  and 
Computer  Software  CI(s)  in  the  system  segment. 

To  be  clear  as  to  what  we  are  discussing,  a  Requirements  Trace- 
ability  Matrix  is  a  list  of  the  Section  3  and  Section  5  requirements  down 
the  left  side  of  a  page,  with  a  series  of  vertical  columns  for  each  of  the 
subtier  elements  across  the  page.  Usually,  the  Section  3  and  Section  5 
requirement  paragraphs  should  be  expanded  to  provide  the  necessary 
clarification,  identification,  and  separation  of  requirements.  The  matrix 
should  provide  a  column  to  identify  each  system  requirement  by 
paragraph  number,  sequence  number  within  the  paragraph  (a,  b,  c,  etc.), 
and  name.  The  matrix  should  indicate  the  allocation  (full,  partial,  or  zero) 
for  each  requirement  to  each  of  the  lower-tier  elements  in  the  appropriate 
column.  A  separate  matrix  usually  would  be  prepared  for  each  tier.  The 
top-level  matrix  would  indicate  the  allocation  of  system  requirements  to 
system  segments.  The  next  level  matrices  would  be  for  the  system 
segments.  Each  of  these  matrices  would  indicate  the  allocation  of  system 
segment  requirements  to  the  top-level  Hardware  CI(s)  and  Computer 
Software  CI(s)  in  that  system  segment.  Additional  matrices  could  be 
prepared  for  lower  tiers. 
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The  matrix  cannot  be  prepared  until  the  Hardware  CI(s)  and  Com¬ 
puter  Software  CI(s)  in  each  of  the  system  segments  have  been  identified. 
The  matrix  helps  summarize  and  trace  the  allocation  of  system  require¬ 
ments  to  lower  tiers.  The  matrix  cannot  be  used  to  add  requirements  that 
are  not  already  in  Sections  3  and  5  of  the  system  specification.  The  matrix 
can  be  used  only  to  help  verify  the  requirements  that  are,  or  should  be, 
included  in  Sections  3  and  5  of  subtier  specifications.  Because  an  actual 
matrix  is  extensive,  it  should  always  be  prepared  as  a  separate  document 
and  simply  referenced  in  this  paragraph,  if  the  matrix  is  included  at  all. 
This  is  an  optional  requirement  as  far  as  the  specification  is  concerned; 
however,  other  contract  provisions  may  require  the  completion  of  the 
Requirements  Traceability  Matrices  by  the  contractor.  In  that  case,  it 
could  be  referenced  here  as  a  guidance  document. 

Although  the  Requirements  Traceability  Matrix  may  be  included  in 
the  system  specification,  the  allocation  of  the  system  requirements  to 
lower  tiers  occurs  after  the  system  specification  has  been  prepared  and 
does  not  add  any  new  system-level  information.  For  that  reason,  the 
words  included  in  this  paragraph  in  the  model  specification  indicate  that 
the  matrix  is  Not  applicable.  If  for  some  reason  the  words  are  changed  to 
include  or  reference  the  matrix,  be  sure  that  the  words  do  not  try  to  make 
the  matrix  mandatory  or  impose  requirements  that  should  be  in  other 
paragraphs  of  the  specification  or  in  the  SOW  or  CDRL.  If  the  contractor  is 
required  to  prepare  or  update  the  matrix,  that  requirement  must  be  stated 
in  the  contract  SOW  and  the  matrix  listed  in  the  CDRL. 

3.5.8  Subsection  3.8.  PRECEDENCE 

This  subsection  generally  starts  with  a  title  heading  for  the  para¬ 
graphs  that  follow. 

Note  that  DI-CMAN-80008A  does  not  establish  a  requirement  for  subtier  paragraphing  in 
Subsection  3.8.  For  the  convenience  of  those  using  the  Model  Space  System  Specification 
(Appendix  A),  a  suggested  set  of  subtier  paragraphs  is  included.  The  paragraphs  in  Appendix 
A  are  typical  boilerplates  for  a  space  system  specification.  These  paragraphs  are  intended 
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to  help  resolve  any  conflicts  that  may  occur  among  the  high-priority  program  requirements. 
These  high-priority  requirements  typically  include  design  and  performance  requirements, 
schedule  constraints,  and  system  life  cycle  cost.  Unless  some  attempt  is  made  to  formally 
establish  relative  values  or  priorities  among  the  various  program  requirements,  inconsistent 
priorities  may  be  used  by  the  various  participants  as  they  make  trade  studies  and  decisions 
regarding  detail  requirements  for  items  at  lower  levels  of  assembly.  The  boilerplate  material 
shown  in  Appendix  A  should  be  changed  if  changes  are  needed  to  specify  the  needs  of  a 
particular  space  system. 

Paragraph  3.8.1,  Conflicts,  states  the  overall  considerations  in 
resolving  conflicts  that  may  occur  with  referenced  documents.  The  general 
rule  is  that  requirements  stated  in  a  document  take  precedence  over  con¬ 
flicting  requirements  given  in  referenced  documents.  In  the  early  phases 
of  a  system  acquisition,  the  identification  of  external  system  interfaces 
usually  requires  the  referencing  of  other  system  specifications,  documents 
prepared  by  other  agencies,  and  descriptions  of  government-furnished 
property.  Usually,  it  is  not  desirable  to  provide  a  definitive  order  of 
precedence  for  conflicts  that  may  be  identified  involving  these  external 
interfaces.  For  example,  if  the  requirements  in  a  specification  for  inter¬ 
facing  equipment  were  given  precedence  over  the  requirements  stated  in 
the  system  specification,  then  the  system  contractors  would  seem  to  be 
obligated  to  constantly  follow  any  changes  that  might  be  made  by  others  in 
the  interfacing  equipment.  On  the  other  hand,  if  the  requirements  stated 
in  the  system  specification  took  precedence  over  those  in  the  referenced 
external  interface  documents,  the  system  might  not  work  properly  if  there 
were  a  conflict  in  the  interfaces.  Of  course,  it  is  important  that  any  con¬ 
flicts  in  the  external  interfaces  be  identified  and  resolved.  Rather  than 
provide  a  definitive  order  of  precedence,  the  boilerplate  words  in  the 
model  specification  direct  the  resolution  of  unresolved  conflicts,  such  as 
any  external  interface  conflicts,  to  the  contracting  officer.  In  this  way,  the 
program  office  will  be  notified  of  any  apparent  conflicts,  and  the  appro¬ 
priate  program  office  actions  can  be  taken  for  their  resolution. 

Note  that  there  are  minor  differences  in  conflict  resolution  in  this  guidebook  and  in  DI-CMAN- 
80008A  (Appendix  I  of  MIL-STD-490A).  This  guidebook  addresses  all  orders  of  precedence 
issues  in  Paragraph  3.8  rather  than  some  in  Section  2  and  some  in  Paragraph  3.8.  Also,  in 
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Section  2  of  DI-CMAN-80008A  (Appendix  I  of  MIL-STD-490A),  it  is  suggested  that  require¬ 
ments  in  referenced  higher-tiered  specifications  take  precedence  over  requirements  contained 
in  the  specification  being  prepared.  Generally,  that  is  the  desire  of  everyone  involved;  but 
saying  it  in  the  specification  does  not  make  it  so,  and  the  contractor  implementing  the  specifi¬ 
cation  does  not  have  any  way  to  assure  compliance.  This  guidebook  simply  refers  external 
interface  conflicts  to  the  contracting  officer,  and  that  should  avoid  any  confusion  or  problems. 

Paragraph  3.8.2,  Requirement  Weighting  Factors,  states  the  relative 
importance  of  the  various  requirements  included  within  the  specification, 
since  all  requirements  may  not  be  of  equal  importance.  This  may  be 
accomplished  by  indicating  the  relative  importance  of  the  various  para¬ 
graphs  or  requirements  in  the  specification.  For  example,  in  a  particular 
system  specification,  it  might  be  stated  that  interface  requirements  have 
the  highest  priority,  that  performance  and  weight  of  space  items  have 
slightly  lower  priority,  and  that  all  other  requirements  have  equal  but 
even  lower  priority  in  the  system  design. 

In  addition,  requirements  that  are  not  hard  mandatory  require¬ 
ments  can  be  included  using  may,  preferred,  should,  or  shall,  where 
practicable  to  indicate  their  relative  importance  as  contrasted  to  the  shall 
requirements.  In  essence,  the  use  of  weighting  factors  simply  documents 
current  practice.  The  suggested  four  weighting  factors  may  be  expanded 
using  other  verbs  or  modifiers  if  warranted,  may  be  decreased  by  using 
only  two  or  three  categories,  or  may  not  be  used  at  all,  depending  upon  the 
content  of  the  specification  being  prepared.  Unless  other  contract  provi¬ 
sions  are  made,  only  the  shall  requirements  would  be  compliance  require¬ 
ments  for  the  contractors.  Requirements  with  lower  weighting  factors 
would  be  goals.  However,  the  use  of  the  weighting  factors  in  the  specifica¬ 
tion  allows  a  contract  or  SOW  to  be  written  to  interpret  the  desired  con¬ 
tractor  compliance  with  the  other  weighted  requirements.  For  example,  if 
the  program  office  wanted  to  impose  a  very  strict  technical  management 
on  the  contractor  during  a  particular  ;^hase  of  an  acquisition,  the  SOW 
might  require  contracting  officer  approval  whenever  the  contractor 
wanted  to  implement  any  alternatives  to  the  shall,  where  practicable 
requirements.  The  SOW  also  might  require  technical  approval  during  the 
preliminary  design  review  of  alternatives  to  the  preferred  or  should 
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requirements,  or  it  could  state  other  possible  contractor  actions  that  might 
be  desired.  Note  that  weighting  factors  are  appropriate  only  in  specifica¬ 
tions  during  the  early  program  phases  and  are  not  appropriate  in  detailed 
product  specifications  intended  to  support  a  production  contract.  The 
general  rule  is  that  weighting  factors  should  not  be  used  unless  they  serve 
a  useful  purpose  in  the  particular  specification. 

Paragraph  3.8.3,  Life  Cycle  Cost,  states  the  general  requirement 
that  system  life  cycle  cost  is  an  important  requirement.  This  paragraph  is 
intended  to  clearly  require  costs,  schedules,  and  other  program 
considerations  to  be  considered  in  the  prioritization  of  the  requirements 
and  in  the  design  process.  The  Model  specification  (Appendix  A)  provides 
typical  wording;  however,  the  last  two  sentences  of  this  paragraph  should 
be  modified  to  state  the  particular  order  of  precedence  established  for  the 
program.  If  an  order  of  importance  of  the  requirements  is  not  established 
with  respect  to  life  cycle  cost,  the  last  two  sentences  should  be  deleted.  In 
establishing  the  priorities,  it  should  be  obvious  that  minimizing  the  system 
life  cycle  cost  may  not  result  in  minimizing  the  program  life  cycle  cost  if 
the  program  includes  several  systems.  Of  course,  minimizing  the  program 
life  cycle  cost  is  the  goal.  However,  usually  it  can  be  assumed  that  mini¬ 
mizing  the  life  cycle  cost  for  each  of  the  systems  is  sufficient.  Because  a 
system  is  normally  the  responsibility  of  a  single  government  agency, 
minimizing  the  system  life  cycle  cost  is  the  most  that  should  be  expected 
within  the  usual  program  management  structures. 

Paragraph  3.8.4,  Supplementary  Specifications  and  Standards, 
provides  general  instructions  regarding  the  order  of  precedence  and  course 
of  action  to  be  taken  if  the  documents  referenced  in  the  system  specifi¬ 
cation  do  not  provide  the  reliability,  quality  level,  or  technical  performance 
required. 

3.5.9  Subsection  3.9.  QUALIFICATION 

DI-CMAN-80008A  states  that  this  subsection  should  state  the 
requirements  for  system  qualification.  The  boilerplate  material  shown  in 
Appendix  A,  Subsection  3.9,  usually  is  appropriate,  but  it  should  be 
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changed  if  changes  are  needed  to  specify  the  needs  of  a  particular  space 
system. 


Note  that  there  is  a  conflict  in  DI-CMAN-80008A  between  the  required  content  of  Subsection 
3.9  and  the  required  content  of  Section  4.  DI-CMAN-80008A  states  that  quality  assurance 
provisions  should  be  stated  in  subsections  of  Section  4.  D1-CMAN-80008A  also  states  that 
each  qualification  test  shall  be  identified  in  a  separate  subparagraph  in  Subsection  3.9,  and  the 
specific  application  shall  be  described.  Qualification  is  stated  to  be  the  verification  or  valida¬ 
tion,  as  applicable,  of  capabilities  in  a  specific  application.  Subsection  3.9  of  DI-CMAN-80008A 
also  states  that  requirements  also  shall  be  included  for  the  conditions  of  testing,  the  time 
(program  phase)  of  testing,  period  of  testing,  number  of  items  to  be  tested,  and  any  other 
pertinent  qualification  requirements.  The  situation  is  further  complicated  by  those  who 
maintain  that  qualification  never  is  imposed  at  the  system  level  of  assembly,  so  qualification 
requirements  would  not  be  appropriate  in  the  system  specification.  This  guidebook  resolves 
these  conflict  by  stating  all  qualification  requirements  in  Section  4.  Subsection  3.9  should  not 
include  details  but  should  reference  Section  4.  This  allows  the  details  of  all  testing,  including 
qualification,  to  be  in  Section  4  where  they  belong.  Qualification  requirements  are  an 
important  and  costly  aspect  of  the  quality  assurance  provisions  imposed  on  various  subtier 
elements  of  the  system  to  assure  mission  success,  so  it  is  appropriate  to  include  them  in  the 
system  specification. 

3.5.10  Sub.section  3.10.  STANDARD  SAMPLE 

D1-CMAN-80008A  apparently  was  trying  to  establish  a  standard 
format  for  subtier  items,  since  this  heading  clearly  does  not  apply  to  a 
system  or  system  segment  specification.  DI-CMAN-80008A  states  that  this 
subsection  shall  describe  requirements,  if  applicable,  for  the  production  of 
one  or  more  standard  samples.  Standard  samples  shall  be  limited  to  the 
illustration  of  qualities  and  characteristics  that  cannot  be  described  using 
detailed  test  procedures  or  design  data  or  that  cannot  be  definitively 
expressed.  The  Not  applicable  shown  in  Appendix  A,  in  Subsection  3.10,  is 
appropriate  for  any  system  or  system  segment  specifications  imaginable. 
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3.5.11 


Subsection  3.11.  PREPRODUCTIQN  SAMPLE.  PERIODIC 
PRODUCTION  SAMPLE.  PILOT.  OR  PILOT  LOT 

DI-CMAN-80008A  apparently  was  trying  to  establish  a  standard 
format  for  subtier  items,  since  this  heading  clearly  does  not  apply  to  a 
system  or  system  segment  specification.  DI-CMAN-80008A  states  that  this 
subsection  shall  describe  requirements,  if  applicable,  for  producing  a  pre- 
production  or  periodic  production  sample,  a  pilot  model,  or  a  pilot  lot.  The 
Not  applicable  shown  in  Appendix  A,  Subsection  3.11,  is  appropriate  for 
any  system  or  system  segment  specifications  imaginable. 

3.6  SECTION  4.  QUALITY  ASSURANCE  PROVISIONS 

As  shown  in  Appendix  A,  the  quality  assurance  provisions  for  the 
system  are  stated  in  subsections  of  Section  4.  The  quality  assurance  pro¬ 
visions  are  intended  to  provide  the  technical  requirements  for  the  inspec¬ 
tion  and  test  programs  to  be  developed  and  implemented  during  the 
acquisition.  In  a  system  specification,  the  quality  assurance  provisions 
would  not  be  stated  in  such  detail  as  to  constitute  a  complete  quality 
assurance  program.  The  intent  of  the  quality  assurance  requirements  in 
the  system  specification  is  primarily  to  state  general  top-level  require¬ 
ments  for  formal  verification  and  testing  of  the  system,  and  subtier  ele¬ 
ments,  that  will  be  imposed  during  the  system  acquisition.  That  includes 
testing  compliance  with  the  system  performance,  system  design  character¬ 
istics,  system  interfaces,  and  system  operability  stated  in  Section  3  of  the 
specification.  Because  the  same  quality  assurance  provisions  may  not 
apply  to  all  elements  of  the  system,  care  should  be  taken  to  identify  the 
applicability  of  the  requirements.  In  addition,  the  requirements  stated 
should  establish  the  framework  for  the  quality  program  and  testing 
program  in  sufficient  detail  so  that  adequate  test  equipment,  facilities, 
personnel,  training,  procedures,  and  other  items  may  be  identified  for  all 
levels  of  assembly  as  early  in  the  acquisition  process  as  possible.  The 
expansion  of  the  system-level  quality  assurance  provisions  into  subtier 
details  normally  would  occur  in  lower-tier  specifications,  in  test  planning 
documents,  and  in  test  procedure  documents. 
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3.6.1 


Subsection  41.  RESPONSIBILITY  FOR  INSPECTION 

This  subsection  usually  states  the  general  boilerplate  requirement 
that  the  contractor  is  responsible  for  all  tests  and  inspections. 

Note  that  Subsection  4.1  in  DI-CMAN-80008A  does  not  establish  an  organization  for  subtier 
paragraphs.  For  the  convenience  of  those  using  Appendix  A,  a  set  of  subtier  paragraphs  is 
included  to  cover  the  suggested  subject  areas.  On  the  other  hand,  the  boilerplate  material 
shown  in  Appendix  A  should  be  changed  if  changes  are  needed  to  specify  the  needs  of  a 
particular  space  system. 

Paragraph  4.1.1,  Philosophy  of  Testing,  shall  describe  the  overall 
testing  philosophy  and  approach  that  is  to  be  used  to  show  that  all  of  the 
system  requirements  have  been  satisfied. 

Paragraph  4.1.2,  Location  of  Testing,  shall  specify  the  location(s) 
for  the  performance  of  tests. 

3.6.2  Subsection  4.2.  SPECIAL  TESTS  AND  EXAMINATIONS 

This  usually  is  only  a  title  heading  for  the  subtier  paragraphs. 

Note  that  Subsection  4.1  in  DI-CMAN-80008A  does  not  establish  an  organization  for  subtier 
paragraphs.  For  the  convenience  of  those  using  Appendix  A,  a  required  set  of  subtier  para¬ 
graphs  and  subparagraphs  is  included  to  clearly  list  all  tests  and  inspections  and  to  separate 
general  boilerplate  requirements  applicable  to  operational  elements  from  those  applicable  to 
nonoperational  elements.  Typically,  most  of  the  identified  test  requirements  are  for  the 
operational  elements  of  the  space  system.  Because  the  requirements  are  different,  the  test 
requirements  for  the  operational  elements  must  be  separated  into  those  applicable  to  space 
elements  (space  vehicle  equipment)  and  those  applicable  to  nonspace  elements  (typically 
ground  equipment  and  computer  software).  On  the  other  hand,  the  boilerplate  material  shown 
in  Appendix  A  should  be  changed  if  changes  are  needed  to  specify  the  needs  of  a  particular 
space  system. 

Paragraph  4.2.1,  Classification  of  Inspections  and  Tests,  identifies 
all  the  inspection  and  test  categories  included  in  the  specification.  This 
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paragraph  is  essentially  the  table  of  contents  for  the  remainder  of  Sub¬ 
section  4.2.  In  Appendix  A  the  organization  is  as  follows: 

Inspections  and  Tests  of  Operational  Elements  of  the  On-orbit  Space  System  (4.2.2) 

Inspections  and  Tests  of  Space  Elements  (4 .2.2.1) 

Space  Vehicle  Parts,  Materials,  and  Process  Controls  (4.2.2.1.1) 

Space  Vehicle  Design  Verification  Tests  (4.2.2.1.2) 

Qualification  Tests  (4.2.2.1.3) 

Acceptance  Tests  (4.2.2.1.4) 

Space  Vehicle  Service  Life  Verification  Tests  (4 .2.2. 1.5) 

Inspections  and  Tests  of  Ground  Equipment  and  Computer  Software  (4.2.2.2) 

Part,  Material,  and  Software  Unit  Development  Tests  and  Evaluations 
(4.22.2.1) 

Step  1  •  Component  Tests  and  Evaluation  (Development)  (4.2.2.2.2) 

Step  2  •  Configuration  Item  Compliance  Tests  (Qualification  and 
Acceptance)  (4.2.2.2.3) 

Step  2.1  -  Single  Cl  or  CSCI  Compliance  Tests 
(4.2.22.3.1) 

Step  2.2  -  Combined  CI/CSCI  Compliance  Tests 
(4.2.22.32) 

Step  3  -  Integrated  System  Testing  (4.2.2.2.4) 

Step  4  -  Initial  Operational  Test  and  Evaluation  (lOTE)  (4.2.2  2.5) 

Step  5  -  Follow-on  Operational  Test  and  Evaluation  (FOT&E)  (4.2.22.6) 
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Inspections  and  Tests  of  Operational  Elements  of  the  On-orbit  Space  System  Not  Required  for 
On-orbit  Support  (Nonoperational  Elements)  (4.2.3) 

Prelaunch  Validation  Tests  (4.2.4) 

Space  Vehicle  Prelaunch  Validation  Tests  (4 .2.4.1) 

Launch  System  Prelaunch  Validation  Tests  (4.2.4.2) 

On-orbit  System  Prelaunch  Validation  Tests  (4.2.4.3) 

Certification  for  Flight  (4.2.4.4) 

Paragraph  4.2.2,  Inspections  and  Tests  of  Operational  Elements  of 
the  On-orbit  Space  System,  generally  starts  as  a  title  heading  for  the  sub- 
paragraphs  that  follow.  There  is  a  subparagraph  added  in  Paragraph  4.2.2 
for  each  inspection  and  test  category  identified  for  the  operational  ele¬ 
ments  of  the  on-orbit  space  system.  It  is  intended  that  the  inspection  and 
test  categories  would  be  the  same  as  those  planned  for  lower-tier  specifi¬ 
cations. 


Paragraph  4.2.2. 1,  Inspections  and  Tests  of  Space  Elements, 
generally  starts  as  a  title  heading  for  the  subparagraphs  that  follow. 

Paragraph  4. 2. 2. 1.1,  Space  Vehicle  Parts,  Materials,  and  Process 
Controls,  is  intended  to  document  those  quality  assurance  provisions  that 
assure  the  continuing  quality  of  the  critical  space  elements  of  the  system. 
The  primary  reason  for  requiring  the  supplier  to  adhere  rigidly  to  a  certifi¬ 
able  manufacturing  baseline  is  to  provide  assurance  that  subsequent  pro¬ 
duction  will  be  equivalent  in  every  respect  to  the  space  items  that  were 
qualified  initially.  This  is  particularly  important  in  cases  in  which  produc¬ 
tion  is  not  continuous,  and  there  is  the  possibility  that  critical  information 
will  be  lost  during  the  production  gaps.  For  example,  if  the  baseline 
materials  and  processes  that  produced  acceptable  items  are  not  known,  it 
is  much  more  difficult  to  take  corrective  actions  if  problems  occur  in  some 
subsequent  production  run. 
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Paragraph  4. 2. 2. 1.2,  Space  Vehicle  Design  Verification  Tests, 
summarizes  requirements,  if  any,  for  the  completion  of  verification  testing 
of  system  designs  to  demonstrate  compliance  with  the  specified  perform¬ 
ance  margins.  The  design  verification  tests  identified  in  the  system  speci¬ 
fication  usually  would  be  concerned  with  high  risk  areas,  new  technology, 
new  applications,  or  new  interfaces  that  should  be  verified  by  special  tests 
early  in  the  acquisition  process. 

Paragraph  4. 2. 2. 1.3,  Qualification  Tests,  summarizes  what  qualifi¬ 
cation  tests  are  required  for  the  space  vehicle  and  the  space  vehicle  com¬ 
ponents. 

Paragraph  4. 2. 2. 1.4,  Acceptance  Tests,  summarizes  what  tests  and 
inspections  will  be  the  basis  for  government  acceptance  of  the  space 
vehicle  and  of  the  space  vehicle  components  submitted  for  delivery  by  the 
contractor. 

Paragraph  4. 2. 2. 1.5,  Space  Vehicle  Service  Life  Verification  Tests, 
summarizes  any  tests  or  inspections  required  to  monitor  aging  of  poten¬ 
tially  life-limited  devices  and  to  verify  life  extensions. 

Paragraph  4.2.3,  Ground  Equipment  and  Computer  Software 
Inspections  and  Tests,  generally  starts  as  a  title  heading  for  the  subpara¬ 
graphs  that  follow.  There  is  a  subparagraph  added  in  Paragraph  4.2.2  for 
each  inspection  and  test  category  identified.  The  primary  test  phases  in 
the  ground  equipment  specifications  usually  are  identified  as  the  Steps  1, 
2,  3,  4,  and  5  tests.  Not  all  steps  need  to  be  specified,  and  different  names 
may  be  used,  depending  upon  the  program  characteristics  and  the  specifi¬ 
cation  subject.  Each  step  may  have  substeps  defined,  depending  upon  the 
system  complexity.  In  addition,  there  may  be  part,  material,  and  process 
quality  assurance  requirements,  including  tests,  imposed  directly  or  indi¬ 
rectly  by  the  specifications.  Qualification  and  acceptance  testing  of  all 
piece  parts  and  of  all  materials  typically  is  required  by  the  contractor 
simply  to  avoid  assembling  defective  items.  The  next  higher  level  of 
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assembly,  the  subassembly,  may  require  in-process  screening  or  inspec¬ 
tions;  but  these  also  usually  are  determined  by  the  contractor  and  not 
specified  for  ground  equipment  in  the  system  specifications. 

In  system  specifications,  the  lowest  level  of  assembly  for  ground 
equipment  that  usually  is  discussed  is  the  component  level.  Step  1 
development  tests  of  critical  hardware  components  and  of  all  software 
components  usually  are  required.  Testing  at  the  next  higher  level  of 
assembly,  the  subsystem,  usually  is  not  specified,  and  any  in-process 
screening  or  inspection  requirements  would  be  determined  by  the  con¬ 
tractor.  The  next  major  higher  level  of  assembly  for  ground  equipment  is 
the  Cl  level  where  Step  2  testing  is  required.  The  qualification  (if  re¬ 
quired)  and  acceptance  tests  for  each  hardware  Cl  are  specified  by  the 
Step  2.1  tests.  The  qualification  tests  for  each  CSCI  also  are  specified  by 
the  Step  2.1  tests.  Expanding  strings  of  CIs  and  CSCIs  then  are  tested  in 
additional  steps  until  all  ground  equipment  CIs  and  CSCIs,  including  their 
interfaces,  are  tested.  The  integrated  system  tests  of  Step  3  incorporate 
the  interfaces  of  the  ground  equipment  and  software  with  other  elements 
of  the  system,  such  as  the  space  or  launch  vehicles.  The  Step  3  tests  are 
intended  to  demonstrate  design  requirements  of  the  system  related  to 
such  items  as  performance,  EMC,  reliability,  maintainability,  system  safety 
(hazardous  noise,  radiation  hazards,  pressure  vessels),  logistics  support- 
ability,  operational  procedures,  and  personnel  performance.  The  Step  3 
tests  usually  are  divided  into  two  parts,  the  Preliminary  Integrated  System 
Tests  of  Step  3.1  and  the  Final  Development  Tests  and  Evaluation  of  Step 
3.2.  Step  4  tests,  the  Initial  Operational  Tests  and  Evaluation,  are  con¬ 
ducted  with  the  equipment  in  its  operational  location,  using  operational 
software,  and  by  the  operational  personal  assigned.  The  Step  4  tests  are 
intended  to  demonstrate  and  verify  the  initial  operational  requirements  of 
the  system.  Satisfactory  completion  of  the  Step  4  tests  is  the  milestone  for 
initial  operational  capability  (IOC).  Step  5  tests,  the  Follow-on  Operational 
Test  and  Evaluation  (FOT&E),  are  intended  to  demonstrate  subsequent 
capabilities  to  support  all  missions. 

Paragraph  4.2.3. 1,  Parts  and  Materials  Qualification  and  Accept¬ 
ance.  is  intended  to  document  those  quality  assurance  provisions  that 


d:SSD-GB-4A  Pi  3/a;EDC-MAC-#l 3 


92 


assure  the  continuing  quality  of  the  critical  ground  elements  of  the  system. 
The  tests  of  parts  and  material  for  ground  equipment  are  the  qualification 
and  acceptance  tests  imposed  on  the  suppliers  by  the  part  and  material 
specifications  plus  any  in-house  verification  tests  such  as  may  be  con¬ 
ducted  by  incoming  inspection.  Usually,  the  system  specifications  would 
require  the  use  of  standard  military  parts,  where  applicable,  so  the  testing 
of  nonstandard  parts  would  be  the  only  possible  concern  that  might  be 
addressed.  For  ground  equipment,  as  contrasted  to  space  equipment,  the 
parts  and  material  testing  usually  is  not  as  critical;  if  that  is  the  case,  no 
government  requirements  need  be  imposed.  That  would  mean  that  the 
contractor  would  determine  the  part  and  material  tests  to  be  imposed  on 
the  suppliers  and  those  to  be  conducted  by  incoming  inspection. 

Paragraph  4.2.3. 2,  Step  1  -  Component  Tests  and  Evaluation 
(Development),  states  requirements  for  the  development  tests  conducted 
by  the  development  contractor  to  support  the  design  and  development  of 
ground  equipment  hardware  components  and  software  components.  These 
tests  are  intended  to  demonstrate  feasibility,  minimize  design  risk,  and 
evaluate  design  alternatives  and  tradeoffs  required  to  best  achieve  the 
program  objectives.  These  tests  are  conducted  by  the  contractor  develop¬ 
ing  the  component.  Usually,  the  computer  software  development  tests  and 
evaluations  are  required  to  be  conducted  in  an  approved  test  bed. 

Paragraph  4.2.3.3,  Step  2  -  CI/CSCI  Compliance  Tests  (Qualification 
and  Acceptance),  states  requirements  for  the  compliance  tests  of  ground 
equipment  hardware  components  and  software  components  that  are  con¬ 
ducted  to  assure  CI/CSCI  compliance  with  their  allocated  requirements. 
These  are  formal  tests  conducted  using  detailed  test  procedures.  Comple¬ 
tion  of  these  tests  usually  is  made  contingent  on  the  satisfactory  comple¬ 
tion  of  subsequent  system  tests. 

Paragraph  4.2.3.3.1,  Step  2.1  -  Single  Cl  or  CSCI  Compliance  Tests, 
states  the  formal  test  requirements  for  qualification  and  acceptance  of 
components  and  CIs.  Compliance  tests  for  computer  software  components 
are  specified  as  Preliminary  Qualification  Tests  (PQTs)  and  for  CSCIs  as 
Formal  Qualification  Tests  (FQTs).  Compliance  tests  for  the  ground 
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equipment  hardware  components  usually  are  specified  as  the  configuration 
item  acceptance  tests;  however,  qualification  of  critical  components  or  CIs 
also  could  be  required.  These  are  formal  tests  conducted  by  the  contractor 
developing  the  component  or  Cl,  using  detailed  test  procedures.  Usually, 
the  computer  software  qualification  tests  are  required  to  be  conducted  in 
an  approved  test  bed. 

Paragraphs  4.2.3.3.2,  4.2.3.3.3,  and  4.2.3.3.4,  Steps  2.2,  2.3,  and  2.4 
-  Combined  CI/CSCI  Compliance  Tests,  state  requirements  for  the  tests 
where  expanding  strings  of  CIs  and  CSCIs  are  tested  until  all  ground 
equipment  CIs  and  CSCIs,  including  their  interfaces,  are  involved.  These 
integrated  CI/CSCI  tests  are  conducted  at  the  contractor's  test  facility  to 
the  extent  feasible;  however,  the  final  test  step  in  this  sequence  (Step  2.4) 
should  be  conducted  at  the  launch  site  or  another  appropriate  operational 
location.  The  tests  in  the  initial  steps  usually  are  conducted  by  the  system 
segment  contractor  with  support  from  the  contractors  developing  the  CIs. 
Step  2.4,  the  final  test  step  in  this  sequence,  is  conducted  by  the  system 
contractor  with  support  from  the  system  segment  contractors  and  the 
contractors  developing  the  CIs  as  may  be  required.  However,  both  the 
locations  and  the  agencies  conducting  the  tests  are  not  appropriate  subjects 
for  the  specification.  The  specification  should  focus  on  the  technical 
requirements  for  the  tests. 

Paragraph  4. 2.3. 4,  Step  3  -  Integrated  System  Testing,  states 
requirements  for  integrated  system  tests  that  incorporate  the  interfaces  of 
the  ground  equipment  and  software  with  other  elements  of  the  system, 
such  as  the  space  or  launch  vehicles.  The  Step  3  tests  are  intended  to 
demonstrate  design  requirements  of  the  system  related  to  such  items  as 
performance,  EMC,  reliability,  maintainability,  system  safety  (hazardous 
noise,  radiation  hazards,  pressure  vessels),  logistics  supportability,  opera¬ 
tional  procedures,  and  personnel  performance.  The  Step  3  tests  usually 
are  divided  into  Preliminary  Integrated  System  Tests  (Step  3.1)  and  Final 
Development  Tests  and  Evaluation  (Step  3.2). 

Paragraph  4. 2. 3. 4.1,  Step  3.1  -  Preliminary  Integrated  System 
Tests,  is  the  required  initial  test  to  verify,  to  the  extent  feasible,  that  the 
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system  performs  as  specified.  If  a  reliability  demonstration  is  required,  it 
may  be  run  in  parallel.  If  a  maintainability  demonstration  is  required,  it 
will  be  a  separate  test.  This  step  also  includes  any  required  system  safety 
tests  and  evaluations.  These  could  include  such  areas  as  hardware  inspec¬ 
tions  for  electrical  and  mechanical  hazards,  including  caution  labeling; 
evaluation  of  the  fire  suppression  system;  evaluation  of  emergency  sys¬ 
tems;  use  of  any  hazardous  materials;  possibility  of  personnel  exposure  to 
any  equipment  and  ambient  noise  levels  considered  hazardous  (See  APR 
161-35);  RF  radiation  testing  to  determine  actual  levels  of  radiation  to 
which  personnel  may  be  exposed  and  to  evaluate  the  accuracy  of  the 
mathematical  predictions  of  radiation  levels;  proper  functioning  of  any 
radiation  warning  systems;  and  proper  procedures  for  inspection,  opera¬ 
tion,  and  maintenance  of  pressure  vessels.  These  Preliminary  Integrated 
System  Tests  are  ct  .ducted  by  the  system  contractor  with  support  from 
the  system  segment  contractors  and  the  contractors  developing  the  CIs  as 
may  be  required.  However,  both  the  location  and  the  agencies  conducting 
the  tests  are  not  appropriate  subjects  for  the  specification.  The  specifi¬ 
cation  should  focus  on  the  technical  requirements  for  the  tests. 

Paragraph  4.2. 3. 4.2,  Step  3.2  -  Final  Development  Test  and  Evalua¬ 
tion  (FDT&E),  is  a  comprehensive  verification  of  the  system  performance 
that  is  conducted  by  the  government  with  support  from  the  system  con¬ 
tractor  and  the  system  segment  contractors.  The  interfaces  of  the  ground 
equipment  and  software  with  operational  elements  of  the  system,  such  as 
actual  space  or  launch  vehicles,  may  be  by  simulation.  As  before,  the 
specification  should  focus  on  the  technical  requirements  for  the  tests. 

Paragraph  4.2.3. 5,  Step  4  -  Initial  Operational  Test  and  Evaluation 
(lOTE),  states  requirements  for  tests  conducted  at  an  operational  site  in  an 
operational  configuration,  utilizing  operational  software  by  assigned  opera¬ 
ting  personnel,  to  demonstrate  initial  operational  requirements.  Satisfac¬ 
tory  completion  of  Step  4  testing  is  the  basis  for  establishing  the  IOC. 
Conducting  these  tests  is  the  responsibility  of  the  government;  however, 
support  from  the  system  contractor  and  the  system  segment  contractors 
may  be  required  by  their  contracts.  As  before,  the  specification  should 
focus  on  the  technical  requirements  for  the  tests. 
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Paragraph  4.2.3. 6,  Step  5  -  Follow-on  Operational  Test  and 
Evaluation  (FOT&E),  states  requirements  for  testing  that  are  conducted  as  a 
follow-on  to  Step  4  tests  to  demonstrate  additional  operational  require¬ 
ments.  Conducting  these  tests  is  the  responsibility  of  the  government; 
however,  support  from  the  system  contractor  and  the  system  segment 
contractors  may  be  required  by  their  contracts.  As  before,  the  specifi¬ 
cation  should  focus  on  the  technical  requirements  for  the  tests. 

Paragraph  4.2.4,  Prelaunch  Validation  Tests,  is  intended  to  docu¬ 
ment  any  special  prelaunch  validation  tests  to  be  included  as  part  of  the 
prelaunch  test  sequence  that  might  influence  the  system  design.  Pre¬ 
launch  validation  tests  of  the  first  operational  system  or  of  the  first 
operational  space  vehicle  usually  are  conducted  as  part  of  the  Step  4 
testing.  All  subsequent  operational  space  vehicles  are  subjected  to  pre¬ 
launch  validation  tests  to  assure  that  there  are  no  out-of-tolerance  condi¬ 
tions  or  anomalous  behavior. 

Paragraph  4.2.4. 1,  Space  Vehicle  Prelaunch  Validation  Tests,  is 
intended  to  document  any  special  space  vehicle  prelaunch  validation  tests 
to  be  included  as  part  of  the  prelaunch  test  sequence  that  might  influence 
the  system  design.  Prelaunch  validation  tests  of  the  first  operational  space 
vehicle  may  be  conducted  as  part  of  the  Step  4  testing.  All  subsequent 
operational  space  vehicles  are  subjected  to  prelaunch  validation  tests  to 
assure  that  there  are  no  out-of-tolerance  conditions  or  anomalous  behav¬ 
ior. 


Paragraph  4.2. 4. 2,  Launch  System  Prelaunch  Validation  Tests,  is 
intended  to  document  any  special  launch  vehicle  prelaunch  validation  tests 
to  be  included  as  part  of  the  prelaunch  test  sequence  that  might  influence 
the  system  design.  Prelaunch  validation  tests  of  the  first  operational 
launch  vehicle  may  be  conducted  as  part  of  the  Step  4  testing.  All  subse¬ 
quent  launch  vehicles  are  subjected  to  prelaunch  validation  tests  to  assure 
that  there  are  no  out-of-tolerance  conditions  or  anomalous  behavior. 
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Paragraph  4.2.4.3,  On-orbit  System  Prelaunch  Validation  Tests,  is 
intended  to  document  any  special  on-orbit  system  prelaunch  validation 
tests  to  be  included  as  part  of  the  prelaunch  test  sequence  that  might 
influence  the  system  design.  Prelaunch  validation  tests  of  the  first  opera¬ 
tional  on-orbit  system  may  be  conducted  as  part  of  the  Step  4  testing.  All 
subsequent  on-orbit  systems  are  subjected  to  prelaunch  validation  tests  to 
assure  that  there  are  no  out-of-tolerance  conditions  or  anomalous  behav¬ 
ior. 


Paragraph  4.2. 4.4,  Certification  for  Flight,  is  intended  to  document 
any  special  requirements  to  be  included  as  part  of  the  prelaunch  test 
sequence  that  might  influence  the  system  design.  The  concept  of  product 
flight  accreditation  is  used  to  assure  that  the  critical  components  satisfy  all 
requirements  that  have  been  found  necessary  for  successful  space  mis¬ 
sions.  Flight  accreditation  is  a  process  in  which  the  status  of  each  item  is 
under  continuing  evaluation  from  program  inception  to  final  accreditation 
for  flight.  The  extent  of  reviews  required  is  dependent  upon  the  specific 
qualification  and  production  status  of  the  items  to  be  flown  and  the  suit¬ 
ability  of  their  as-qualified  design  for  the  intended  mission  application. 
Unless  specifically  excluded,  flight  accreditation  should  incorporate  all 
technical  assessment  activity  from  inception  of  the  program  through 
manufacturing,  qualification,  transportation,  handling,  storage,  and  post¬ 
delivery  operations  leading  to  final  installation  and  checkout  prior  to  flight. 
Upon  completion  of  the  integrated  system  tests,  the  test  history  of  the 
integrated  equipment  shall  be  reviewed  to  determine  its  acceptability  for 
flight.  The  assessment  activity  involves  incremental  reviews  and 
culminates  in  documentation  that  all  accreditation  requirements  have  been 
met.  After  completion  of  the  final  review  for  each  item,  the  acceptability 
or  nonacceptability  for  flight  is  documented. 

3.6.3  Subsection  4.3.  REQUIREMENTS  CROSS  REFERENCE 

This  subsection  generally  references  a  table  or  listing  that  corre¬ 
lates  each  system  requirement  in  Sections  3  and  5  to  the  qualify  assurance 
provisions  specified  in  Section  4  of  the  specification.  This  matrix  is  an 
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optional  feature  that  helps  summarize  the  requirements.  The  matrix  can¬ 
not  be  used  to  add  requirements  that  are  not  already  in  Sections  3,  4,  and 
5  of  the  speciHcation.  Because  an  actual  matrix  is  extensive,  it  should  be 
prepared  as  a  separate  document  and  simply  referenced  in  this  paragraph 
if  it  is  included.  If  the  contractor  is  required  to  prepare  or  update  the 
matrix,  that  requirement  must  be  stated  in  the  contract  and  listed  in  the 
CDRL, 


The  Requirements  Cross  Reference  matrix  usually  is  a  list  of  the 
Section  3  and  Section  5  requirements  down  the  left  side  of  the  page  with  a 
series  of  vertical  columns  across  the  page.  There  would  be  a  vertical 
column  to  indicate  the  verification  method  to  indicate  the  assembly  level, 
and  another  to  indicate  the  corresponding  Section  4  paragraph.  Usually, 
the  Section  3  and  Section  5  requirement  paragraphs  should  be  expanded  to 
provide  the  necessary  clarification,  identification,  and  separation  of  re¬ 
quirements.  The  matrix  should  provide  a  column  to  identify  each  system 
requirement  by  paragraph  number,  sequence  number  within  the  para¬ 
graph  (a,  b,  c,  etc.),  and  name.  The  verification  methods  column  should 
indicate  whether  the  verification  method  to  be  used  is  by: 

A  -  ANALYSIS 

D  -  DEMONSTRATION 

I  -  INSPECTION 

T  -  TEST 

N/A  -  NOT  APPLICABLE 

The  assembly  level  column  would  be  to  indicate  which  of  the 
following  assembly  levels  is  to  be  used  for  the  verification  method 
specified: 

1  -  PART  OR  MATERIAL 

2  -  COMPONENT 

3  -  VEHICLE  LEVEL 

4  -  SYSTEM  LEVEL 

The  matrix  is  a  list  of  the  Section  3  and  Section  5  requirements  and 
indicates  during  which  of  the  Section  4  quality  assurance  tests  or  inspec¬ 
tions  each  requirement  would  be  verified.  The  matrix  also  indicates  how 
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the  Section  3  and  Section  5  requirements  that  are  not  intended  to  be 
verified  by  the  quality  assurance  provisions  would  be  verified,  if  at  all. 

For  that  reason,  a  Not  applicable  classification  is  provided  as  well  as  a  5y 
analysis  classification.  Care  should  be  taken  so  that  the  contractor  does  not 
interpret  the  lack  of  a  By  analysis  classification  to  mean  that  an  analysis  is 
not  required.  Just  because  a  requirement  is  to  be  verified  by  a  quality 
assurance  provision  does  not  mean  that  an  analysis  is  not  required  in  the 
design  process.  Most  system-level  requirements  involve  ground  equip¬ 
ment,  computer  software,  as  well  as  space  equipment;  the  quality  assur¬ 
ance  provisions  typically  would  be  different  for  each  of  these  elements. 
That  may  mean  that  each  of  the  Section  3  paragraphs  should  be  expanded 
to  provide  the  necessary  clarification  and  separation  of  requirements. 
Usually,  this  would  occur  automatically  in  lower-tier  specifications. 

Although  the  verification  cross  reference  matrix  may  be  included, 
the  requirements  and  quality  assurance  provisions  in  a  system  specifi¬ 
cation  usually  are  of  such  broad  scope  that  the  matrix  may  have  little 
value  except  as  a  summary  or  checklist.  For  that  reason,  the  words 
included  in  this  paragraph  in  the  Model  specification  indicate  that  the 
matrix  is  for  guidance  and  is  provided  simply  as  summary  information.  If 
for  some  reason  the  words  are  changed  to  make  the  matrix  mandatory,  be 
sure  that  the  words  do  not  try  to  impose  requirements  that  should  be  in 
the  SOW  or  CDRL.  Remember  that  the  specification  will  not  impose 
management  tasks  or  data  delivery  tasks  on  the  contractor.  For  example, 
the  matrix  will  not  establish  requirements  for  a  government  review  or 
audit  of  the  By  analysis  data  packages.  Government  reviews  and  audits 
are  management  tasks  for  the  contractor  and  are  not  imposed  on  the 
contractor  by  words  in  the  specification. 

3.7  SECTION  5.  PREPARATION  FOR  DELIVERY 

This  is  a  major  section  heading  for  text  to  specify  requirements  for 
the  preparation  of  the  system  and  all  its  components  for  delivery,  includ¬ 
ing  packaging  and  handling.  This  section  shall  include  requirements  to 
document  any  nonstandard  practices  in  appropriate  system  end  item 
specifications.  This  section  may  impose  requirements  to  comply  with 
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standard  practice  by  referencing  appropriate  military  specifications  and 
standards  to  be  used  as  the  basis  for  preparing  Section  5  of  each  specifi¬ 
cation  for  system  end  items. 

However,  there  are  seldom  any  preservation,  packaging,  packing, 
or  marking  requirements  that  might  influence  the  space  system  design,  so 
the  Not  applicable  shown  in  Appendix  A  usually  is  the  proper  entry.  The 
preparations  for  delivery  requirements  for  space  systems  and  items 
typically  are  included  in  other  documents  or  in  lower-level  product  speci¬ 
fications  where  preservation,  packaging,  packing,  and  marking  of  the 
packages  is  directly  applicable. 

3.8  SECTION  6.  NOTES 

As  shown  in  Section  6  of  Appendix  A,  the  Notes  section  is  used 
primarily  to  include  explanatory  information  that  may  be  beneficial  to  the 
contractor  in  understanding  the  requirements  of  the  specification.  Com¬ 
pliance  requirements  never  are  stated  in  the  Notes  section.  In  addition, 
the  Notes  section  may  contain  information  useful  to  associate  contractors 
or  interfacing  agencies.  If  the  notes  become  extensive,  some  or  all  of  the 
notes  may  be  included  as  one  or  more  nonmandatory  appendices. 

3.8.1  Subsection  6.1.  INTENDED  USE 

This  subsection  should  state  the  intended  uses  of  the  space  system 
being  specified  (see  Subsection  1.4). 

Note  that  DI-CMAN-80008A  says  that  the  mission  and  the  threat  should  be  addressed  in  this 
subsection,  which  is  not  a  compliant  section  of  the  specification.  If  it  is  believed  that  the 
system  should  be  designed  to  meet  the  mission  and  to  operate  in  (or  survive)  the  threat 
requirements,  then  this  guidebook  should  require  both  the  mission  and  the  threat  to  be  stated 
as  requirements  (Section  3).  To  be  fully  compliant  with  DI-CMAN-80008A,  the  Model  specifi¬ 
cation  (Appendix  A)  includes  Subparagraphs  6.1.1  for  missions  and  6.1 2  for  threat,  but  each 
only  references  Section  3  paragraphs.  Actually,  it  is  unnecessary  for  the  Notes  section  to 
reference  the  text;  so  Subparagraphs  6.1 .1  and  6.1 .2  may  be  deleted,  arxJ  compliance  with  Dl- 
CMAN-80008A  may  be  obviated. 
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3.8.2 


This  subsection  states  information  which  should  be  included  in 
invitations  for  bids  and  purchasing  documents.  It  is  primarily  to  provide 
instructions  to  the  contracting  officer  to  help  avoid  oversights.  Reference 
should  be  made  to  all  parts  of  the  specification  in  which  options  can  be 
exercised  or  contracting  officer  actions  are  indicated.  For  example,  if 
different  classifications  of  the  system  are  defined  in  Subsection  1.2,  or 
when  precedence  requirements  are  specified  in  Subsection  3.8,  specific 
ordering  data  flagging  those  items  may  be  appropriate.  If  only  one  item  of 
ordering  data  is  listed,  it  follows  the  Subsection  6.2  heading.  If  more  than 
one  item  is  listed,  the  Subsection  6.2  heading  is  only  a  title  heading,  and 
each  item  of  ordering  data  is  a  separate  paragraph. 

Note  that  DI-CMAN-80008A  does  not  address  this  or  any  of  the  following  subject  areas 
covered  in  the  Notes  section  of  Appendix  A.  The  suggested  set  of  notes  should  be  added  in 
subtier  paragraphs  for  the  convenience  of  those  using  the  specification. 

3.8.3  Subsection  6.3.  DEFINITIONS 

In  this  subsection,  the  various  key  terms  that  are  subject  to 
ambiguous  or  variant  interpretations  should  be  defined.  As  a  general 
practice,  terms  that  are  used  only  in  a  single  paragraph  or  subsection 
should  be  defined  in  the  text  where  they  are  first  used.  Definitions  that 
are  included  in  the  text  or  that  are  defined  adequately  in  the  referenced 
documents  need  not  be  repeated  in  this  subsection.  Two  different  defini¬ 
tions  should  not  be  given  for  the  same  term  in  a  single  document  nor 
should  two  different  terms  be  used  for  the  same  thing.  A  glossary  of 
terms  and  their  definitions  that  are  included  in  the  commonly  referenced 
military  specifications  and  standards  is  available  for  use  as  a  checklist  to 
avoid  creating  new  definitions.  Terms  that  are  defined  adequately  in 
Webster's  Collegiate  Dictionary  or  in  the  IEEE  Standard  Dictionary  of 
Electrical  and  Electronic  Terms  (IEEE  STD  100-197)  should  not  be  defined 
in  the  specification. 
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3.8.4  Subsection  6.4.  ABBREVIATIONS  AND  ACRONYMS 

This  subsection  provides  a  single  reference  point  where  all  abbre¬ 
viations  and  acronyms  used  in  the  document  are  decoded.  However,  the 
use  of  abbreviations  and  acronyms  in  the  specification  text  should  be 
minimized  as  a  service  to  those  not  intimately  familiar  with  the  program 
who  may  have  occasion  to  use  the  document.  If  the  list  of  acronyms  is 
extensive,  the  text  of  the  specification  will  be  difficult  to  understand.  In 
that  case,  to  enable  the  text  of  the  specification  to  be  read  easily,  the 
acronyms  should  be  spelled  out  the  first  time  they  are  used  in  each  para¬ 
graph  or  the  first  time  they  are  used  on  each  page.  An  extensive  acronym 
list  should  be  prepared  as  an  appendix,  or  as  a  separate  document,  which 
then  would  be  referenced  in  this  paragraph. 

3.8.5  Subsection  6.5.  GUIDANCE  DOCUMENTS 

This  subsection  lists  any  other  documents  that  may  be  of  help  to 
the  contractor  or  those  using  or  reviewing  the  document.  Any  require¬ 
ments  included  in  the  documents  listed  in  this  subsection  are  not  compli¬ 
ance  requirements  as  far  as  the  system  specification  is  concerned.  Docu¬ 
ments  li'ted  in  this  subsection  should  not  be  listed  in  Section  2,  and  the 
documents  listed  in  Section  2  should  not  be  listed  in  this  subsection. 

3.8.6  Subsection  6.6.  TAILORED  APPLICATIONS 

This  subsection  addresses  the  contractor's  actions  if  he/she 
believes  there  are  cost  or  technical  excesses  or  other  problems  with  the 
specified  requirements  including  the  referenced  requirements. 

3.8.7  Other  Subsections 

Other  subsections  may  be  added  if  needed  to  provide  other 
guidance  information  that  may  be  pertinent  to  the  particular  system,  to 
the  system  contractors,  or  to  others  using  the  document. 
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3.9 


As  shown  in  Appendix  A,  appendices  may  be  used  to  specify 
extensive  details  which  are  the  subject  of  the  basic  specification.  An 
appendix  must  be  within  the  scope  of  the  specification,  and  it  must  be 
referenced  in  the  basic  portion  of  the  specification  to  indicate  applicability. 
For  the  convenience  of  the  reader,  a  statement  indicating  whether  or  not 
any  of  the  material  in  an  appendix  is  a  mandatory  part  of  the  specification 
should  appear  as  a  preamble  at  the  beginning  of  each  appendix.  The 
appendices,  if  any,  usually  are  an  integral  part  of  the  specification. 
Identification  of  appendices  is  alphabetical  such  as  Appendix  A,  Appendix 
B,  and  Appendix  C.  To  the  extent  it  is  practicable,  the  internal 
arrangement  of  each  appendix  should  parallel  the  arrangement  of  the 
specification.  The  first  subsection  of  each  appendix  should  be  Scope,  and 
the  second  subsection  should  be  Applicable  Documents.  Only  documents 
referenced  in  the  appendix  are  listed  in  the  applicable  document  section  of 
the  appendix.  Other  subsections  would  depend  upon  the  subject  and 
content  of  the  appendix.  As  previously  stated,  documents  referenced  in 
mandatory  appendices  also  are  listed  in  Section  2  of  the  specification. 

If  what  would  otherwise  be  an  appendix  is  bound  separately  due 
to  its  bulk  or  security  classification,  it  still  can  be  called  an  appendix.  In 
that  case,  it  would  be  prepared  like  an  integrally  bound  appendix,  but  it 
would  be  bound  separately  with  the  addition  of  a  cover  and  other  features 
that  might  be  appropriate,  such  as  a  table  of  contents  or  index  If  an 
appendix  is  bound  separately,  a  page  is  inserted  in  the  specification  where 
that  appendix  normally  would  be  located,  indicating  that  it  is  bound 
separately.  Alternatively,  separately  bound  material  can  be  prepared  as 
any  appropriate  document  type  and  then  would  be  treated  as  any  other 
referenced  document.  Whether  or  not  the  separately  bound  material  is 
prepared  as  an  appendix  or  as  some  other  type  of  reference  document,  it 
would  be  listed  in  Section  2  of  the  parent  specification  if  it  is  a  mandatory 
part  of  the  specification.  If  compliance  is  not  mandatory,  it  still  should  be 
listed  in  Section  2  unles'^  the  only  reference  is  in  Section  6,  in  which  case,  it 
should  be  listed  only  in  Subsection  6.5. 
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3.10  INDEX 


An  alphabetical  index  may  be  placed  at  the  end  of  a  specification 
to  permit  ready  reference  to  its  contents.  The  use  of  an  index  is  limited  to 
lengthy  specifications  or  to  those  having  an  extensive  subject  matter 
breakdown. 
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4.  CERTAINTY  OF  TERMS 


Specifications  should  be  written  in  clear  and  simple  language. 

They  should  not  contain  vague,  indefinite,  conflicting,  or  ambiguous 
requirements.  Punctuation  should  be  minimized  by  the  use  of  short,  con¬ 
cise  sentences  with  a  well  planned  word  order.  Plain  language  is  preferred 
to  unfamiliar  expressions  or  trade  usage. 

4.1  ACRONYMS  AND  ABBREVIATIONS 

Acronyms  and  abbreviations  should  be  avoided.  If  it  is  necessary 
to  use  acronyms  or  abbreviations,  the  word  or  term  shall  be  spelled  out  in 
full  the  first  time  it  is  used  in  the  text,  followed  by  the  acronym  or  abbre¬ 
viation  in  parentheses.  Abbreviations  shall  be  in  accordance  with  MIL- 
STD-12,  where  applicable. 

4.2  SYMBOLS 

The  only  symbols  that  shall  be  used  in  the  text  are  degree  (®)  and 
the  -t-,  and  +.  to  express  ranges  or  tolerances.  Other  symbols  may  be  used 
in  equations  and  tables.  Graphic  symbols,  when  used  in  figures,  shall  be  in 
accordance  with  the  graphic  symbols  requirements  applicable  to  engineer¬ 
ing  drawings  as  stated  in  MlL-STD-100. 

4.3  PROPRIETARY  NAMES 

Trade  names,  copyrighted  names,  or  other  proprietary  names 
applying  exclusively  to  the  product  of  one  company  shall  not  be  used 
unless  the  item(s)  cannot  be  described  adequately  because  of  the  technical 
involvement,  construction,  or  composition.  In  such  instances,  one,  and  if 
possible  several,  commercial  products  should  be  included,  followed  by  the 
words  or  equal  to  assure  wider  competition  and  that  bidding  will  not  be 
limited  to  a  particular  make  specified.  The  same  applies  to  a  manufac¬ 
turer's  item  numbers  or  drawing  numbers  for  minor  items  when  it  is 
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impracticable  to  specify  the  exact  requirements  in  the  specification. 

Insofar  as  practical,  the  particular  characteristics  required  shall  be 
included  to  provide  a  standard  against  which  or  equal  may  be  measured. 

4.4  CATCH-ALL  REQUIREMENTS 

It  should  be  recognized  that  general  catch-all  requirements  in 
specifications  will  produce  only  substantial  compliance  or  substantial 
completion  by  the  supplier.  In  other  words,  general  and  unspecific  terms 
such  as  best  design  practice,  smooth,  good  workmanship,  black  finish, 
clean,  or  suitable  for  the  intended  purpose  should  be  used  only  to  state 
requirements  where  limited  supplier  performance  will  be  acceptable.  If 
strict  compliance  to  a  requirement  is  desired,  the  requirement  must  be 
specific  and  capable  of  measurement  to  the  accuracies  specified.  Because 
there  may  be  characteristics  of  materials,  parts,  items,  and  systems  that 
are  impossible  to  define  exactly  or  to  measure  in  a  universally  acceptable 
way,  the  use  of  general  catch-all  requirements  may  have  a  place  in  some 
specifications.  The  inclusion  of  these  general  requirements  requiring  only 
substantial  compliance  does  not  reduce  the  supplier’s  commitment  for 
strict  compliance  to  all  of  the  definitive  requirements.  In  other  words,  the 
doctrines  of  strict  compliance  and  substantial  compliance  are  not  incom¬ 
patible,  but  they  should  be  understood  by  those  preparing  the  specifica¬ 
tion.  It  should  also  be  recognized  that  if  a  dispute  arises  regarding  the 
interpretation  of  a  requirement,  the  supplier’s  interpretation,  if  reasonable, 
will  generally  prevail. 

4.5  CONSISTENCY 

A  consistency  of  terms  used  in  a  specification  also  is  important  in 
achieving  clarity.  If  two  or  more  terms  are  used  for  the  same  thing,  it  may 
create  confusion  as  to  what  is  really  required.  To  avoid  that  possibility, 
the  most  generally  acceptable  term  should  be  selected  and  used  through¬ 
out  the  document.  If  different  terms  are  used,  they  normally  would  be 
construed  to  be  different  things  or  to  have  different  interpretations. 
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Another  type  of  uncertainty  occurs  when  a  subparagraph  in  the 
specification  is  not  related  to  the  parent  paragraph.  In  that  case,  require¬ 
ments  can  be  overlooked  easily  or  invalidated.  For  example,  the  inclusion 
of  requirements  in  the  definitions,  or  the  inclusion  of  inspection  require¬ 
ments  in  design  requirements,  causes  confusion  and  generally  invalidates 
the  mislocated  requirements. 

4.6  LIMITED  USAGE  TERMS 

Usage  limitations  of  certain  terms  are  as  follows: 

a.  Use  of  and/or.  The  term  andlor  shall  not  be  used  in  specifi¬ 
cations.  In  specifications  and  standards,  where  definitive, 
precise  language  is  imperative,  the  phrase  and/or  has  no  place. 

b.  Use  of  flammable  and  nonflammable.  The  terms  flammable 
and  nonflammable  shall  be  used  in  specifications  in  lieu  of  the 
terms  inflammable  and  noninflammable. 

c.  Use  of  will.  Will  may  be  used  only  to  express  a  declaration  of 
purpose  on  the  part  of  the  government  or  when  simple  futurity 
is  required  in  stating  a  fact.  Because  of  these  limitations,  the 
use  of  will  should  be  infrequent  in  specifications. 

4.7  CONTRACTUAL  AND  ADMINISTRATIVE  REQUIREMENTS 

The  specification  should  not  include  contractual  or  administrative 
requirements  which  are  properly  a  part  of  the  contract  or  of  the  SOW.  For 
example,  do  not  include  costs,  item  quantities,  delivery  of  data,  data  item 
descnptions,  management  system  requirements,  method  of  payment, 
warranty  provisions,  or  provisions  for  disposing  of  items  damaged  or 
destroyed  in  tests.  The  DoD  standardization  documents  listed  in  DoD 
Directive  5000. 19L,  Vol  II,  Acquisition  Management  Systems  and  Data 
Requirement  Control  List  (AMSDL),  should  not  be  referenced  in  the  specifi¬ 
cation.  The  exception  might  be  a  reference  to  a  management  document  to 
incorporate  technical  requirements  that  it  contains  if  they  are  of  a  type  or 
volume  that  would  make  extraction  impractical. 
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5.  LANGUAGE  STYLE 


5.1  GRAMMAR 

The  United  States  Government  Printing  Office  Style  Manual  shall  be 
used  as  a  guide  to  capitalization,  spelling,  punctuation,  syllabification,  and 
language  style.  Additional  guidelines  that  should  be  followed  are: 

a.  In  stating  limitations,  the  phrase  shall  be  stated  thus;  The 
diameter  shall  be  not  greater  than  ...  for  maximum  limit  or  The 
diameter  shall  be  not  less  than  ...  for  minimum  limit. 

b.  Capitalize  the  words  drawing,  bulletin,  and  so  forth,  only  when 
they  are  used  immediately  preceding  the  number  of  the  refer¬ 
enced  document.  However,  specifications,  standards,  and  hand¬ 
books  will  be  identified  in  the  text  only  by  their  document 
identifier  (MIL-E-000,  not  Specification  MIL-E-000). 

5.2  REFERENCING 

Be  sure  to  read  the  specific  issue  of  a  referenced  document  to 
assure  the  applicability  of  the  requirements.  Tailoring  of  the  references 
should  be  accomplished  to  limit  the  applicability  of  the  requirements. 
Additional  guidelines  that  should  be  followed  are: 

a.  Referenced  documents  shall  be  cited  thus; 

(1)  conforming  to  ... 

(2)  as  specified  in  ... 

(3)  in  accordance  with  ... 

In  any  case,  use  the  same  wording  throughout  a  given 
document  and  a  series  of  directly  related  documents. 
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b.  Unless  otherwise  specified  shall  be  used  to  indicate  an 
alternative  course  of  action.  The  phrase  shall  always  come  at 
the  beginning  of  the  sentence  and,  if  possible,  at  the  beginning 
of  the  paragraph. 

c.  When  referring  to  a  requirement  in  the  specification  which  is 
obvious  or  not  difficult  to  locate,  the  simple  phrase  as  specified 
herein  is  sufficient  and  should  be  used. 

d.  The  phrase  ...to  determine  compliance  with...  or  ...to  determine 
conformance  to...  should  be  used  in  place  of  ...to  determine 
compliance  to....  In  either  case,  use  the  same  wording  through¬ 
out. 

Note  that  the  identification  number,  version,  applicable  change  notice,  date 
of  issue,  and  complete  title  are  given  in  Section  2  for  the  referenced  docu¬ 
ments.  The  reference  to  a  document  within  the  text,  however,  should  be 
by  the  identifier  number  only  and  should  not  indicate  the  version,  applic¬ 
able  change  notice,  date  of  issue,  or  title  for  the  document.  In  that  way, 
discrepancies  can  be  avoided  between  the  text  reference  and  the  Section  2 
listing.  Also,  revisions  to  documents  can  be  incorporated  simply  by  revis¬ 
ing  the  listing  in  Section  2.  For  a  similar  reason,  references  never  should 
be  made  to  paragraph  numbers  of  the  referenced  documents  listed  in 
Section  2.  References  in  the  text  that  limit  the  applicability  of  a  document 
should  indicate  the  subject  matter  (usually  the  paragraph  title)  rather  than 
the  paragraph  number. 

5.3  NUMBERS 

Numbers  that  include  decimal  digits  and  numbers  10  and  larger 
are  always  written  using  the  actual  digits,  such  as,  0.03,  6.1,  10,  10.1,  151, 
1510.2,  and  so  forth.  The  sentence  structure  used  should  be  such  that 
numbers  expressed  using  digits  do  not  begin  a  sentence.  Numbers  one 
through  nine  usually  are  written  out  unless  they  are  for  units  of  measure¬ 
ment  or  are  closely  associated  with  the  use  of  digits.  For  example,  a  person 
should  write  one  dog,  2  meters,  three  books,  4  ohms,  five  buildings,  6  sec¬ 
onds,  seven  chairs,  8  volts,  or  nine  apples,  if  each  item  and  number  were 
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isolated  from  the  others.  That  sentence,  however,  does  not  illustrate  good 
practice,  because  the  use  of  digits,  or  numbers  written  out,  should  be  con¬ 
sistent  within  the  same  sentence  and  within  the  same  paragraph  or  related 
paragraphs.  The  use  of  all  digits  would  be  the  best  practice  in  the  example 
and  in  most  cases. 


1 1 1 
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6.  FORMAT 


The  format  used  for  a  specification  is  intended  to  help  present  the 
requirements  to  readers  in  a  clear  and  logical  manner.  Inconsistencies  in 
format  and  organization  can  distract  a  reader  from  understanding  the 
requirements  presented.  In  addition,  time  may  be  wasted  trying  to  find 
material  or  trying  to  decide  if  there  are  some  hidden  meanings  implied  by 
the  format  inconsistencies.  Therefore,  consistent  format  rules  should  be 
established  and  uniformly  followed  throughout  each  specification.  Varia¬ 
tions  from  the  MIL-STD-490  format  rules  have  been  made  in  a  few  cases 
in  this  guidebook,  when  the  variation  represents  a  current  practice  and  the 
variation  is  consistent  with  more  recent  standardization  documents,  such 
as  DoD  41 20.3 -M. 

Although  the  format  guidelines  chosen  for  a  document  are  a  matter 
of  personal  preference,  there  are  many  advantages  that  accrue  by  the 
consistent  use  of  the  same  rules  in  all  specifications.  The  guidelines  pre¬ 
sented  are  intended  to  provide  the  basis  to  achieve  this  desired  format 
consistency.  On  the  other  hand,  some  format  variations  may  be  appro¬ 
priate  among  various  specifications  depending  upon  the  following: 

a.  Length  of  the  document 

b.  Number  of  major  headings  (sections  plus  appendices) 

c.  Content  of  the  document  such  as  the  number  and  size  of  figures 
and  tables 

d.  Limitations  of  the  equipment  to  be  used  in  the  document 
preparation  (word  processor,  typewriter,  typesetter,  etc.) 

e.  Documentation  standards  of  the  preparing  organization 

In  all  cases,  the  page  size  shall  be  8-1/2  x  11  inches  with  a  2-inch 
margin  at  the  binding  edge  to  allow  large-size  three-hole  punching  and 
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binding.  A  3/4-inch  margin  at  the  top  of  the  page,  above  the  header,  and  a 
1 /2-inch  margin  at  the  bottom  of  the  page,  below  the  page  number,  should 
be  provided.  Printing  should  be  single  spaced  on  both  sides  of  the  paper. 


6.1  TITLE  PAGE 

The  first  page  of  the  specification  is  the  title  page  and  cover.  It 
includes  the  specification  number,  the  appropriate  federal  supply  code  of 
the  preparing  organization  from  Cataloging  Handbook  H4-1  (code  identifi¬ 
cation  number),  and  date  of  issue  in  the  upper  right  corner.  If  no  contrac¬ 
tor  is  involved  in  preparing  the  specification,  the  code  identification  num¬ 
ber  of  the  preparing  government  organization  is  used.  The  federal  supply 
code  for  specifications  prepared  by  SSD  is  07868  as  shown  in  Appendix  A. 
The  specification  title  is  centered  a  few  lines  lower,  and,  down  the  page, 
the  contract  number,  the  CDRL  sequence  number,  the  name  of  the  acqui¬ 
sition  agency  that  the  specification  was  prepared  for,  and  finally  the  name 
of  the  organization  preparing  the  specification. 

If  the  specification  has  a  security  classification,  the  title  page,  and 
all  other  pages,  must  be  marked  in  accordance  with  provisions  of  the  DoD 
Industrial  Security  Manual  for  classified  material,  DoD  5220.22M,  and 
other  applicable  security  instructions.  The  title  page  is  page  i  but  is  un¬ 
marked.  The  back  of  the  title  page  is  ii  when  the  specification  is  printed 
on  both  sides  of  the  paper.  Page  ii  may  contain  coordination  or  approval 
signatures,  or  it  may  be  left  blank. 

6.2  TABLE  OF  CONTENTS 

A  table  of  contents  should  be  included  as  part  of  the  specification  if 
the  specification  is  lengthy,  i.e.,  over  30  pages  in  length.  The  table  of  con¬ 
tents,  if  included,  would  start  on  page  iii  if  the  specification  were  printed 
on  both  sides  of  the  paper.  This  page  begins  with  the  heading  "CONTENTS" 
in  capital  letters.  Identification  numbers  and  headings  for  sections,  sub¬ 
sections,  and  paragraphs  shall  be  shown  in  the  listing  (three  digits)  and 
may  be  shown  for  subparagraphs  (four  digits).  The  contents  also  shall 
include  a  reference  to  all  appendices  and  the  index.  The  contents  should 
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include  a  separate  listing  for  the  figures  and  tables,  particularly  when  the 
figures  or  tables  are  not  incorporated  in  the  text  adjacent  to  the  paragraph 
where  they  are  referenced  A  separate  caption  FIGURES  shall  head  the  list 
of  figures,  and  a  caption  TABLES  shall  head  the  list  of  tables.  Page  num¬ 
bers  shall  be  shown  for  each  listing  in  the  table  of  contents. 

6.3  PAGE  HEADER 

A  page  header  identifying  the  document  and  the  date  of  issue  is  in 
the  upper  comer  of  each  page  of  the  document  opposite  the  binding  edge, 
i.e.,  in  reversed  position  when  printed  on  both  sides  of  the  page.  The  basic 
page  header  for  an  appendix  should  be  the  same  as  the  header  for  the 
associated  document.  The  appropriate  appendix  identification,  such  as 
"Appendix  A,"  should  be  added  to  the  basic  page  header  for  each  appendix 
if  there  are  numerous  appendices  or  if  one  of  the  appendices  is  lengthy  or 
separately  bound. 

6.4  SECTION  FORMATS 

Most  specifications,  particularly  those  longer  than  30  pages,  are 
prepared  in  a  sectionalized  style  format  where  each  section  starts  at  the 
top  of  an  odd-numbered  page.  In  the  sectionalized  style  format,  the  section 
heading  is  centered  at  the  top  of  the  page  and  starts  on  the  third  line 
below  the  page  header.  The  section  heading  includes  the  section  number, 
and  the  section  title  is  on  the  second  line  below  the  section  number.  The 
section  heading  should  not  be  underlined  but  should  be  typed  with  all 
capital  letters  or  printed  in  bold  face  type.  Three  blank  lines  should  follow 
the  section  heading  to  set  it  apart  from  the  first  subsection  heading  (or 
text). 


Short  specifications,  such  as  those  less  than  30  pages,  should  be 
prepared  in  a  continuous  style  format  with  the  section  number  and  title  on 
the  same  line  and  starting  flush  left.  The  title  is  typed  in  all  capital  letters 
without  underlining  or  alternatively  may  be  printed  in  boldface  type.  The 
first  section  starts  at  the  top  of  page  1,  but  subsequent  sections  are  sepa¬ 
rated  from  the  text  in  the  prior  paragraph  by  two  blank  lines.  A  blank  line 
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should  follow  the  section  heading  to  set  it  apart  from  the  first  subsection 
heading  (or  text). 


6.5  SUBSECTION  AND  PARAGRAPH  HEADINGS 

Subsections,  paragraphs,  and  subparagraphs  are  numbered 
consecutively  within  each  section  of  the  specification,  using  a  decimal  point 
to  separate  the  number  representing  each  breakdown.  The  ^^ubsection 
numbers  start  flush  with  the  left  margin,  and  the  paragraph  numbers  and 
subparagraph  numbers  are  tabbed  in  five  spaces  from  the  left  margin.  The 
titles  start  on  the  same  line  two  spaces  from  the  end  of  the  number.  The 
subsection  titles  should  be  typed  with  all  capital  letters  and  underlined  or 
printed  in  boldface  type.  Paragraph  and  subparagraph  titles  have  the 
initial  letter  of  each  significant  word  in  the  title  capitalized,  and  the  titles 
are  underlined  or  printed  in  boldface  type.  A  blank  line  separates  the 
subsection,  paragraph,  and  subparagraph  headings  from  prior  text,  listings, 
or  headings. 

A  subtier  breakdown  always  has  two  or  more  elements.  What 
would  otherwise  be  a  single  subtier  paragraph  or  subparagraph  should  be 
incorporated  into  the  parent  paragraph.  Note  that  all  the  titles  used  in  the 
first  tier  subparagraph  of  a  parent  paragraph  should  be  different  and 
should  not  duplicate  the  heading  for  the  parent  paragraph. 

The  following  outline  illustrates  the  general  format  for  the  head¬ 
ings  of  a  Section  3  and  of  the  subsections  and  subparagraphs. 
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Example 


SECTION  3 
TITLE 

3.1  FIRST  SUBSECTION  TITLE  (No  text  follows) 

3.1.1  First  Paragraph  Title.  (Text  follows) 

3.1. 1.1  First  Subparagraph  Title.  (Text  follows) 

3. 1.1.2  Second  Subparagraph  Title.  (Text  follows) 

3.1.2  Second  Paragraph  Title.  (Text  follows) 

3.2  SECOND  SUBSECTION  TITLE  (No  Text  follows) 


6.6  LISTINGS 

Short  lists  of  items  within  the  text  are  identified  by  small  letters, 
i.e.,  a.,  b.,  c.,  and  so  forth,  and  usually  are  run  into  the  sentence  structure 
within  the  paragraph.  When  it  is  desirable  to  highlight  the  listing,  or  if  the 
listing  is  lengthy  or  complex,  an  indented  block  style  is  used  for  the  listing. 
A  lengthy  listing  is  one  with  six  or  more  elements.  A  complex  listing  is  one 
that  has  text  associated  with  the  elements  in  the  list  or  that  has  a  second 
tier  list,  i.e.,  a  list  within  a  list. 

The  elements  in  the  f^st  tier  listing  in  the  block  style  are  identi¬ 
fied  by  small  letters,  i.e.,  a.,  b.,  c.,  and  so  forth,  that  are  tabbed  in  10  spaces 
from  the  left  margin.  Second-tier  listings  (listings  within  a  listing)  are 
identified  by  sequential  numbers  in  parentheses,  i.e.,  (1),  (2),  (3),  and  so 
forth,  that  are  tabbed  in  15  spaces  from  the  left  margin.  Usually,  listings 
do  not  have  extensive  text  with  each  element  and  do  not  have  titles. 

Where  titles  are  used,  the  titles  would  be  formatted  similar  to  a  paragraph 
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title  but  blocked  with  the  text  associated  with  the  listing.  A  blank  line  is 
used  to  separate  items  in  a  listing  from  prior  items  in  the  listing  or  from 
prior  text. 

In  those  cases  in  which  the  text  associated  with  a  listing  is  lengthy, 
i.e.,  more  than  two  sentences  per  element,  consideration  should  be  given  to 
reformatting.  Typically,  the  material  should  be  arranged  as  a  series  of 
subtier  paragraphs  under  the  parent  paragraph.  In  other  words,  the 
extensive  text  that  had  been  drafted  as  elements  of  the  listing  would 
become  subtier  paragraphs.  In  some  cases,  it  may  be  desirable  to  retain 
the  highlighting  feature  of  a  listing,  even  when  there  is  extensive  text 
associated  with  each  element.  In  that  case,  each  of  the  elements  should  be 
given  an  identifying  name,  and  a  listing  would  be  prepared  listing  those 
names.  The  extensive  text  then  should  be  arranged  as  subtier  paragraphs 
that  would  follow  the  listing  that  identifies  each  of  tne  elements. 

6.7  TEXT  FORMATTING 

The  organization  of  the  text  in  a  specification  should  require 
paragraph  numbering  of  no  more  than  six  digits,  and  listings,  if  used, 
should  be  limited  to  two  tiers  within  any  paragraph  or  subparagraph.  If 
the  proposed  text  cannot  easily  conform  to  these  restrictions,  serious 
consideration  should  be  given  to  the  transfer  of  some  of  the  proposed  text 
to  subtier  specifications  or  other  documents  that  could  then  be  referenced. 
Quite  often,  this  creation  of  a  subtier  specification  or  other  type  of  docu¬ 
ment  that  can  be  referenced  helps  clarify  the  requirements.  For  example, 
the  creation  of  a  preliminary  space  vehicle  specification  rather  early  in  the 
acquisition  process  may  help  simplify  and  clarify  a  space  system  segment 
specification.  A  reference  to  the  vehicle  specification  in  the  segment  speci¬ 
fication  would  retain  the  requirements  but  would  transfer  the  text  of  the 
detailed  requirements  applicable  only  to  space  or  to  the  space  vehicle  from 
the  segment  specification  to  the  vehicle  specification.  This  would  reduce 
the  bulk  of  the  segment  specification  and  clearly  would  distinguish 
requirements  applicable  only  to  space  or  that  have  been  allocated  to  the 
space  vehicle. 
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When  text  is  associated  with  a  numbered  paragraph  or  subpara¬ 
graph,  a  period  is  placed  at  the  end  of  the  title,  and  the  text  is  run  in  on 
the  same  line  following  the  period.  Subsequent  lines  of  text  are  continued 
flush  with  the  left  margin. 

When  text  is  associated  with  a  listing,  it  is  prepared  in  a  block  for¬ 
mat  with  the  left  margin  of  the  listing  tabbed  in  15  spaces  from  the  left 
margin  of  the  specification  for  first-tier  listings  and  tabbed  in  20  spaces 
for  second-tier  listings. 

In  some  cases,  an  untitled  paragraph  may  be  used  to  highlight 
material  or  to  provide  additional  organization  to  lengthy  material.  Untitled 
paragraphs  are  not  numbered.  Untitled  paragraphs  start  with  the  first 
word  of  the  first  line  tabbed  in  five  spaces  and  continue  with  subsequent 
lines  flush  with  the  left  margin.  A  blank  line  is  used  to  separate  untitled 
paragraphs  from  prior  text,  listings,  or  other  material. 

In  some  cases,  text  is  directly  associated  with  a  section  heading  or 
with  a  subsection  heading.  In  that  case,  it  would  be  formatted  like  an 
untitled  (unnumbered)  paragraph.  The  text  starts  with  the  first  word  of 
the  first  line  tabbed  in  five  spaces  and  continues  with  subsequent  lines 
flush  with  the  left  margin. 

6.8  FORMAT  OF  APPENDICES 

Each  appendix  should  be  formatted  as  though  it  were  a  major 
section  of  the  specification.  However,  a  sectionalized  style  is  always  used, 
so  the  appendix  would  start  at  the  top  of  an  odd-numbered  page.  The 
heading  is  centered  at  the  top  of  the  first  page  and  starts  on  the  third  line 
below  the  page  header.  The  heading  includes  the  identification,  such  as 
APPENDIX  A,  and  the  title  on  the  second  line  below.  The  heading  (includ¬ 
ing  the  title)  should  be  typed  with  all  capital  letters  or  printed  in  boldface 
type.  Three  blank  lines  should  follow  the  section  heading  to  set  it  apart 
from  the  first  subsection  heading  (or  text). 
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Subsections  and  subtler  paragraphs  in  an  appendix  are  formatted 
similar  to  the  equivalent  tier  level  in  the  body  of  a  specification  prepared 
in  a  sectionalized  format. 

A  separately  bound  appendix  would  include  a  separate  title  page 
and  a  table  of  contents  prepared  similar  to  that  for  a  specification. 

6.9  PAGE  NUMBERING 

Page  numbers  shall  be  either  centered  at  the  bottom  of  each  page 
or  placed  in  the  lower  comer  of  the  page  opposite  the  binding  edge,  i.e.,  in 
reversed  positions  when  printed  on  both  sides  of  the  page.  Page  numbers 
should  be  printed  on  otherwise  blank  pages,  and  those  pages  should  be 
marked  "THIS  PAGE  INTENTIONALLY  LEFT  BLANK." 

Pages  usually  are  numbered  consecutively  throughout  the  docu¬ 
ment  with  arable  numerals  starting  with  page  1  corresponding  to  the  page 
where  Section  1,  SCOPE,  starts.  As  indicated  previously,  the  foreword, 
table  of  contents,  and  any  other  pages  prior  to  page  1  in  the  document  are 
numbered  consecutively  with  lower  case  Roman  numerals  starting  with  ii 
as  the  page  after  the  title  page. 

When  the  specification  is  prepared  in  a  sectionalized  style  format 
with  each  section  starting  at  the  top  of  an  odd-numbered  page,  either  con¬ 
tinuous  style  pagination  as  described  above  or  sectionalized  style  pagina¬ 
tion  may  be  used.  For  sectionalized  style  pagination,  a  reference  number 
representing  the  section  number  is  used  with  a  sequential  page  number 
within  each  section.  For  example,  the  page  numbers  for  Section  3  would 
start  3-1,  3-2,  3-3,  and  so  forth  and  for  Section  4  would  start  4-1,  4-2,  4-3, 
and  so  forth.  If  sectionalized  pagination  is  used  for  the  body  of  the  specifi¬ 
cation,  it  should  be  used  for  the  appendices.  The  page  numbers  for  Appen¬ 
dix  A  therefore  would  be  A-1,  A-2,  A-3,  and  so  forth,  to  the  end  of  Appen¬ 
dix  A. 


The  selection  of  the  sectionalized  style  pagination  is  recommended, 
if  the  document  is  produced  on  a  typewriter.  Continuous  style  pagination 
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usually  is  used  if  the  document  is  prepared  on  word  processing  equipment. 
With  most  word  processing  systems,  continuous  style  pagination  is  accom¬ 
plished  easily,  whereas  sectionalized  style  pagination  may  require  the 
creation  of  separate  word  processor  documents  for  each  section.  The  crea¬ 
tion  of  separate  word  processor  documents  can  cause  coordination  prob¬ 
lems  in  formatting,  word  searches,  editing,  and  final  printing.  Therefore, 
when  word  processor  preparation  is  used,  sectionalized  pagination  is 
recommended  only  for  extremely  long  documents  and,  as  indicated  below, 
for  appendices. 

Appendices  usually  are  integrally  bound  with  the  specification,  and 
the  page  numbers  then  may  be  the  sequential  continuation  of  those  used 
in  the  body  of  the  specification.  However,  even  when  continuous  style 
pagination  is  used  in  the  body  of  the  specification,  it  would  be  desirable  to 
paginate  the  appendices  in  a  sectionalized  style  if  they  are  lengthy, 
numerous,  or  separately  bound.  In  that  case,  sequentially  number  the 
pages  of  each  appendix  starting  with  its  first  page.  A  reference  letter 
should  be  used  with  the  page  number  to  identify  the  appendix.  For 
example,  the  page  numbers  for  Appendix  A  would  be  A-1,  A-2,  and  so 
forth  and  for  Appendix  B  would  be  B-1,  B-2,  and  so  forth. 

6.10  TABLES 

A  table  is  an  arrangement  of  data  in  lines  and  columns.  It  shall  be 
used  when  data  can  be  presented  more  clearly  in  this  manner  than  in  text. 
Elaborate  or  complicated  tables  should  be  avoided.  References  in  the  text 
shall  be  sufficiently  detailed  to  make  the  purpose  of  the  table  clear.  The 
table  shall  be  restricted  to  data  pertinent  to  the  associated  text.  The  tables 
shall  be  placed  immediately  following  the  paragraph  or  within  the  para¬ 
graph  containing  the  reference.  If  space  does  not  permit,  the  table  may  be 
placed  at  the  top  of  the  following  page.  If  a  table  is  large  enough  to 
require  a  separate  page,  it  should  be  placed  on  the  first  available  page 
following  the  first  reference  in  the  text.  If  the  number  of  tables  in  a  sec¬ 
tion  is  so  large  that  the  tables  could  disrupt  the  understanding  of  the  text, 
they  should  all  be  placed  in  numerical  sequence  at  the  end  of  the  section  in 
which  they  are  referenced. 
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6.10.1 


Tables  shall  be  boxed  with  border  lines  at  the  sides,  top,  and 
bottom  of  each  table.  Headings  of  tables  should  be  typed  to  ensure  that 
the  vertical  columns  will  accommodate  the  longest  entry  in  the  column  to 
the  greatest  extent  possible.  Horizontal  and  vertical  border  lines  and 
separation  lines  within  the  table  shall  be  typed  or  drawn  with  black 
reproducible  ink  or  reproducible  pencil,  if  they  cannot  be  created 
electronically.  Where  practicable,  data  shall  be  single  spaced  within  the 
table  and  different  groups  of  data  distinguished  through  capitalization, 
indentions,  or  subgrouping. 

6.10.2  Table  Numbering  and  Title 

All  tables  shall  be  numbered  consecutively  throughout  the 
document  with  Roman  numerals  in  the  order  of  their  appearance  in  the 
text.  For  example,  table  numbers  would  start  Table  I,  Table  II,  Table  III, 
Table  IV,  and  so  forth  to  the  end  of  Section  6.  Table  numbers  in  appen¬ 
dices  should  use  a  sectionalized  style  to  associate  the  table  number  with 
the  appendix.  For  example,  table  numbers  in  Appendix  B  would  start 
Table  B-I,  Table  B-II,  and  so  forth.  All  tables  shall  be  titled  with  the  initial 
letter  of  each  significant  word  in  the  title  capitalized.  Table  titles  shall  not 
be  underlined  and  shall  have  a  period  at  the  end  of  the  title.  Table  titles 
shall  be  centered  above  the  table  and  begin  on  the  same  line  with  the  table 
number.  If  the  title  of  the  table  is  too  long  to  end  on  the  same  line,  addi¬ 
tional  lines  may  be  used.  Two  blank  lines  normally  separate  the  bottom 
line  of  the  title  and  the  top  border  line  around  the  table. 

If  a  listing  or  tabulation  appears  within  a  paragraph  as  an  integral 
part  of  that  paragraph  and  obviously  does  not  require  a  title,  the  listing  or 
tabulation  need  not  be  titled,  is  not  given  a  table  number,  and  is  not  to  be 
boxed  in. 
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6.10.3 


Large  tables  may  be  broken  and,  if  possible,  printed  on  facing 
pages  (even  and  odd  pages,  not  on  odd  and  even  pages).  If  a  table  is 
continued  to  additional  page(s),  a  horizontal  line  need  not  be  drawn  at  the 
end  of  the  page,  unless  the  table  is  a  group  or  method  type  that  requires  a 
line  of  separation  between  the  groups.  In  that  case,  it  is  not  desirable  to 
split  a  group  and  carry  part  of  the  listing  to  the  next  page.  The  entire 
group  should  be  completed  on  one  page.  When  the  table  is  continued  to 
the  next  page,  the  title  shall  include  an  appropriate  notation  such  as  (Page 
1  of  2  pages).  Repeat  the  entire  heading  at  the  top  of  the  page  on  which 
the  continuation  is  presented  with  an  appropriate  notation  such  as  (Con¬ 
tinued)  or  (Page  2  of  2  pages).  The  table  shall  be  closed  with  a  horizontal 
line  when  all  data  have  been  typed. 

6.1 1  HGURES 

A  figure  is  an  illustration,  example,  or  graph  and  constitutes  an 
integral  part  of  the  specification.  It  shall  be  clearly  related  to,  and  con¬ 
sistent  with,  the  text  of  the  associated  paragraph.  Figures  should  not  be 
confused  with  numbered  and  dated  drawings  which  shall  not  be  an 
integral  part  of  the  specification  but  shall  be  incorporated  by  reference 
and  listed  in  Section  2  of  the  specification.  The  figures  shall  be  placed 
immediately  following  the  paragraph  or  within  the  paragraph  containing 
the  reference  to  the  figure.  If  a  figure  is  large  enough  to  require  a  sep- 
rate  page,  it  should  be  placed  on  the  first  available  page  following  the  first 
reference  in  the  text.  In  the  case  of  numerous  table  and  figure  references 
on  the  same  page,  this  may  be  several  pages  later.  If  the  number  of 
figures,  or  figures  plus  tables,  in  a  section  is  large  enough  to  disrupt  the 

understanding  of  the  text,  the  figures  should  be  placed  in  numerical 

sequence  at  the  end  of  the  section  in  which  they  are  referenced. 

6.11.1  Figure  Format 

Figures  shall  be  boxed  in  with  border  lines  at  the  sides,  top,  and 

bottom  of  each  figure.  These  border  lines  shall  be  typed  or  drawn  with 
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black  reproducible  ink  or  reproducible  pencil,  if  they  cannot  be  created 
electronically. 


6.11.2  Figure  Numbering  and  Title 

All  figures  shall  be  numbered  consecutively  throughout  the 
document  using  Arabic  numerals,  preferably  in  a  sectionalized  style  in  the 
order  of  their  appearance  in  the  text.  For  example,  figure  numbers  in 
Section  ;•)  would  start  Figure  3-1.,  Figure  3-2.,  Figure  3-3.,  and  so  forth  to 
the  end  of  Section  3;  figure  numbers  in  Section  4  would  start  Figure  4-1., 
Figure  4-2.,  Figure  4-3.,  and  so  forth;  and  figure  numbers  in  Appendix  A 
would  start  Figure  A-1,  A-2,  and  so  forth.  All  figures  shall  be  titled,  with 
the  initial  letter  of  each  significant  word  in  the  title  capitalized.  Figure 
titles  shall  not  be  underlined  and  shall  have  a  period  at  the  end  of  the  title. 
Figure  titles  shall  be  centered  below  the  illustration  or  graphic  and  shall  be 
typed  on  the  same  line  with  the  figure  number.  If  the  title  of  the  figure  is 
too  long  to  be  completed  on  the  same  line,  additional  lines  may  be  used. 

6.11.3  Continuation  of  Figures 

Large  figures  may  be  broken  and,  if  possible,  printed  on  facing 
es  (even  and  odd  pages,  not  on  odd  and  even  pages).  When  a  figure  is 
continued  on  the  next  page,  the  title  shall  include  an  appropriate  notation 
such  as  (Page  1  of  2  pages).  Repeat  the  entire  heading  below  the 
continued  figure  with  an  appropriate  notation  such  as  (Continued)  or 
(Page  2  of  2  pages). 

6.12  FOOTNOTES 

Footnotes  should  be  avoided  if  possible.  When  footnotes  are  used 
in  the  text,  the  footnotes  shall  be  placed  at  the  bottom  of  the  text  on  the 
page  providing  the  footnote  reference(s).  Footnotes  referenced  from  tables 
shall  be  identified  easily  as  such  and  shall  be  stated  one  time  only  for  each 
table  immediately  following  the  table.  Except  where  ambiguity  would 
result,  superscript  Arabic  numerals  should  be  used  to  identify  the  footnote 
reference.  Alternatively,  the  symbol  J  may  be  used  in  conjunction  with 
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the  footnote  numbers  (Examples:  i./,  ZJ,  etc.)  to  identify  both  the  footnote 
reference  and  the  footnote.  Footnotes  shall  be  numbered  consecutively 
starting  with  one  (1)  on  each  page  of  the  specification.  Where  the  use  of 
Arabic  numerals,  the  superscript,  or  the  _/  symbol  will  cause  ambiguity 
(for  example,  in  connection  with  a  chemical  formula),  asterisks,  daggers,  or 
other  symbols  may  be  used. 

6.13  FQLDOIJTS 

Foldouts  shall  be  avoided  except  where  required  for  legibility  or 
when  necessary  for  the  proper  utilization  of  the  data.  Large  tables  or 
figures  that  are  broken  so  that  they  may  be  printed  on  facing  pages  are 
preferred  to  foldouts.  When  foldouts  are  required,  they  should  always  be 
placed  on  a  right-hand  (odd-numbered)  page.  No  printing  and  no  page 
number  should  appear  on  the  back  of  a  foldout,  but  it  shall  be  assigned  an 
even  page  number  for  pagination  purposes.  Suitable  reference  to  the 
location  of  foldouts  shall  be  included  in  the  table  of  contents. 
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7.  CLASSIFIED  MATERIAL 


If  a  proposed  specification  contains  classified  material,  the  System 
Program  Office  may  decide  to  separate  the  classified  portion  of  the  specifi¬ 
cation  from  the  remainder  of  the  specification.  Usually  that  decision  is 
made  when  the  number  of  pages  containing  the  classified  material 
accounts  for  less  than  24  percent  of  the  total  pages  in  the  specification. 

The  classified  material  removed  from  the  specification  would  be  separately 
bound  in  a  classified  appendix.  The  specification  so  modified  would  be 
rewritten  to  reference  the  classified  appendix.  If  the  number  of  pages 
containing  classified  material  accounts  for  more  than  24  percent  of  the 
total  pages  in  the  specification,  the  specification  itself  usually  is  classified. 

A  classified  specification  or  a  separately  bound  classified  appendix  would 
be  marked  in  accordance  with  provisions  of  the  DoD  Industrial  Security 
Manual  for  classified  material,  DoD  5220.22M,  and  other  applicable 
security  instructions. 

In  a  classified  specification  or  separately  bound  classified  appen¬ 
dix,  the  classification  notation  associated  with  each  heading  or  item  of  text, 
i.e.,  (U),  (C),  or  (S),  shall  be  incorporated  as  part  of  tJie  title  or  as  part  of  the 
text  when  the  document  format  rules  presented  in  Chapter  6  of  this 
guidebook  are  interpreted.  However,  note  that  the  page  format  for  a 
classified  document  requires  at  least  a  3/4-inch  margin  at  the  bottom  of 
each  page,  instead  of  1 /2-inch,  to  allow  for  the  classification  markings 
required. 
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8.  CHANGES 


After  initial  publication  of  a  program-peculiar  specification,  many 
factors  will  necessitate  making  changes.  These  include,  but  are  not  limited 
to,  the  correction  of  errors,  the  determination  of  previously  unspecified 
requirements,  the  allocation  of  requirements  to  lower  levels  of  assembly, 
the  results  of  life  cycle  cost  analyses,  the  results  from  trade  studies  of 
alternatives,  the  introduction  of  new  technology,  the  establishment  of 
internal  interface  constraints,  and  the  establishment  of  external  interfaces. 
How  these  changes  are  prepared  and  approved  depends  upon  the  acquisi¬ 
tion  phase  of  the  program,  the  contractual  status  of  the  specification,  and 
the  configuration  control  procedures  established  for  the  program  at  the 
time  the  changes  are  proposed  and  approved.  If  the  specification  repre¬ 
sents  an  approved  contractual  document,  the  changes  usually  would  be 
made  by  the  program  office  approving  specification  change  notices.  If  the 
specification  is  not  on  contract,  or  the  changes  are  extensive,  a  complete 
revision  of  the  specification  would  be  made  rather  than  issuing  a  change 
notice. 


8.1  SPECIFICATION  CHANGE  NOTICES 

A  specification  change  notice  (SCN)  is  used  by  a  contractor  to 
propose,  transmit,  and  record  changes  to  a  program-peculiar  specification. 
The  SCN  numbers  are  assigned  in  the  sequence  that  the  changes  are 
proposed  for  a  particular  issue  of  a  specification  starting  with  Number  1. 
Each  SCN  is  to  be  independent  of  previously  proposed  SCNs  unless  linkage 
is  required  and  is  clearly  established  by  the  SCN.  Because  all  proposed 
SCNs  may  not  be  approved,  the  specification  in  effect  on  a  particular  date 
is  the  basic  issue  plus  all  of  the  SCNs  that  have  been  approved  as  of  that 
date.  Generally,  SCNs  include  revised  pages  that  replace  or  add  to  the 
current  issue  of  the  specification.  The  SCNs  are  not  used  to  make  or 
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transmit  complete  revisions  of  the  specification,  because  the  SCN  number 
sequence  should  start  again  with  Number  1  for  the  revision. 

8.1.1  Paragraph  Changes 

When  new  paragraphs  are  added  to  the  specification,  they  should 
be  added  in  such  a  way  that  renumbering  of  paragraphs  is  unnecessary. 
When  numbered  subsections  or  numbered  paragraphs  are  deleted  from 
the  specification,  the  number  should  be  retained  so  that  the  lemaining 
paragraphs  need  not  be  renumbered.  When  the  number  is  two  or  three 
digits,  the  title  also  should  be  retained  and  Not  applicable  added 
immediately  following  the  title.  When  the  paragraph  number  has  four  or 
more  digits,  the  word  Deleted  should  follow  the  paragraph  number. 

8.1.2  Table  Additions 

Tables  added  after  the  highest  numbered  table  are  assigned  the 
next  higher  number.  If  tables  are  added  between  existing  tables,  the  table 
number  of  the  added  tables  shall  be  that  of  the  preceding  table,  followed 
by  a  lower  case  alphabetical  designation  showing  the  intended  order  of  the 
added  tables.  For  example,  two  tables  added  between  Table  I  and  Table  II 
are  numbered  Table  la  and  Table  Ib,  and  two  tables  added  between  Table 
la  and  Table  Ib  are  numbered  Table  Ia-1  and  Table  Ia-2. 

8.13  Figure  Additions 

Figures  added  after  the  highest  numbered  figure  are  assigned  the 
next  higher  number.  If  figures  are  added  between  existing  figures,  the 
number  of  the  added  figure  shall  be  that  of  the  preceding  figure  followed 
by  a  lower-case  alphabetical  designation  showing  the  intended  order  of  the 
added  figures.  For  example,  two  figures  added  between  Figures  3-1  and 
3-2  are  numbered  3-la  and  3-lb. 
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Generally,  revised  pages  are  prepared  on  which  the  desired 
changes  have  been  incorporated.  These  revised  pages  usually  are  pre¬ 
pared  for  direct  incorporation  in  the  specification  by  the  removal  of  old 
pages  and  the  insertion  of  the  new  pages.  All  revised  pages  are  identified 
in  the  header  by  the  incorporation  of  the  date  of  issue  of  the  SCN  directly 
below  the  specification  number.  All  portions  affected  by  the  change  shall 
be  indicated  by  an  asterisK  or  line  in  the  right-hand  margin  indicating  all 
changed  portions.  If  a  revised  page  replaces  an  original  page,  the  revised 
pages  would  be  numbered  the  same  as  the  page  it  replaces.  If  an  addi¬ 
tional  page  is  to  be  inserted  in  revising  a  page  or  pages,  it  shall  be  identi¬ 
fied  by  the  previous  page  number  followed  by  the  small  letter  a.  For 
example,  if  the  specification  were  printed  on  both  sides  of  the  paper,  and  if 
three  revised  pages  were  to  be  issued  to  replace  the  original  Page  8,  then 
the  SCN  would  transmit  two  sheets  printed  on  both  sides.  The  first  sheet 
would  have  the  original  Page  7  reproduced  with  the  revised  Page  8  printed 
on  the  back  side.  The  second  sheet  would  be  identified  as  Page  8a  and,  on 
the  back  side,  the  third  revised  page  would  be  marked  Page  8b.  Pages  8, 
8a,  and  8b  would  incorporate  the  SCN  date  in  the  header  to  indicate  they 
are  page  changes. 

8.2  REVISIONS 

A  revision  is  a  complete  reissue  of  the  revised  document.  A 
revision  is  accomplished  only  with  the  specific  approval  of  the  contracting 
officer.  Normally,  this  occurs  when  the  number  of  change  notices  becomes 
excessive,  or  when  it  serves  the  purposes  of  the  program  office.  At  that 
time,  the  entire  specification  should  be  analyzed  and  brought  up  to  date  by 
the  revision.  The  revision  is  prepared  as  a  new  document  incorporating,  as 
a  minimum,  all  approved  SCNs.  A  revision  would  be  approved  in  the  same 
manner  as  a  new  specification.  A  specification  revision  is  indicated  by 
incorporating  a  capital  letter  immediately  following  the  specification  num¬ 
ber.  The  first  revision  would  be  marked  with  the  letter  A,  and  succeeding 
revisions  would  be  indicated  by  other  letters  in  alphabetical  sequence. 

The  date  of  issue  would  be  changed  to  the  date  of  the  reissue. 
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For  the  convenience  of  those  using  the  revision,  the  margins  may 
be  marked  with  an  asterisk  or  line  to  indicate  where  new  additions, 
modifications,  corrections,  or  deletions  from  the  previous  issue  were  made. 
If  the  changes  are  marked,  a  note  of  caution  should  be  included  in  the 
Notes  section.  That  note  would  state: 

The  margins  of  this  specification  are  marked  with  an  asterisk  (or 
line)  as  a  convenience  to  indicate  where  changes  were  made  from  the 
previous  issue  (through  SCN  _ ).  The  government  assumes  no  lia¬ 

bility  whatsoever  for  any  inaccuracies  in  the  notations.  Bidders  and 
contractors  are  cautioned  to  evaluate  the  requirements  of  the  docu¬ 
ment  based  on  the  entire  content,  irrespective  of  the  marginal  nota¬ 
tion  and  relationship  to  the  previous  issue. 

In  general,  marking  of  the  changes  is  not  done  in  revisions  of 
program-peculiar  specifications  at  SSD;  in  that  case,  a  statement  to  that 
effect  should  be  included  in  the  Notes  section.  That  note  would  state: 

Symbols  are  not  used  in  this  revision  to  identify  changes  with 
respect  to  the  previous  issue. 
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APPENDIX  A 

MODEL  SPACE  SYSTEM  SPECMCATION 

This  appendix  is  a  Model  space  system  specification  containing  typical 
boilerplate  requirements. 
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SECTION  1 
SCOPE 


1.1  IPEiSTinCATlQN 

This  system  specification  sets  forth  the  requirements  of  the 
(TBS  -  insert  space  system  title  or  nomenclature)  space  system.  This 
system  is  a  major  element  of  the  (TBs  -  insert  program  identification). 
This  system  is  identified  as  (TBS  -  insert  system  identification  number 
or  abbreviation,  if  applicable)  and  is  hereinafter  referred  to  as  the 
system. 

1.2  SYSTEM  OVERVIEW 

This  system  (TBS  -  insert  brief  statement  of  the  purpose  or 
major  function  of  the  system). 

1.3  DOCUMENT  OVERVIEW 

This  specification  sets  fonh  the  performance,  design,  develop¬ 
ment,  construction,  and  test  requirements  of  the  system.  This  specifi¬ 
cation  is  intended  for  compliance  in  the  acquisition  contract  for  the 
system. 

The  term  "TBD"  applied  to  a  missing  requirement  means  that 
the  contractor  should  determine  the  missing  requirement  in  coordi¬ 
nation  with  the  government.  The  term  "TBS"  means  that  the  govern¬ 
ment  will  supply  the  missing  information  in  the  course  of  the  contract. 
The  term  "TBR"  means  that  the  requirement  may  be  reviewed  for 
appropriateness  by  the  contractor  or  the  government  and  may  be 
changed  by  the  government  in  the  course  of  the  contract. 

1.4  SYSTEM  CLASSIFICATIONS 

The  operational  capability  of  this  system  is  to  be  implemented 
incrementally  such  that  the  system  can  iiansition  without  major 
disruption  through  the  following  baseline  classifications; 

a.  IOC  System  (initial  operational  capability  system) 


b.  MOC  System  (middle  operational  capability  system) 
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c.  FOC  System  (final  operational  capability  system) 

The  requirements  stated  in  this  system  specification  that  are 
not  identified  as  applying  to  a  specific  system  classification  apply  to 
all  of  the  system  classifications.  Requirements  stated  as  applying  to 
the  initial  operational  capability  system  also  apply  to  the  middle 
operational  capability  system  and  the  final  operational  capability 
system,  unless  stated  otherwise  in  the  text. 
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SECTION  2 

APPLICABLE  DOCUMENTS 


2.1  GflYEKNMENOI)£lJMEMTS 

The  following  documents  of  the  exact  issue  shown  form  a  part 
of  this  specification  to  the  extent  specified  herein.  In  the  event  of 
conflict  between  the  documents  referenced  herein  and  the  contents  of 
this  specification,  see  Section  3.8. 

SPECmCATIONS: 


Federal 

QQ-N-290A 

12  Nov  71 

Nickel  Plating  (Electrodeposited) 

QQ-C-320B 

10  Apr  87 

Chromium  Plating  (Electro- 
deposited) 

(TBS) 

Militarv 

MIL-M-3171C 

14  Mar  74 

Notice  3 

Magnesium  Alloy,  Processes  for 
Pretreatment  and  Prevention  of 
Corrosion  on 

MIL-E-4158E  (USAF) 
11  Jan  73 
Amendment  3 
31  Dec  85 

MIL-C-5541C 
4  Apr  81 

MIL-F-7179F 
20  May  85 


Electronic  Equipment,  Ground; 
General  Specifications  for 


Chemical  Conversion  Coatings  on 
Aluminum  Alloys 

Finishes,  Coatings,  and  Sealants 
for  the  Protection  of  Aerospace 
Weapons  Systems,  General 
Specification  for 
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MIL-M-8090F 

01  Feb  74 

Mobility,  Towed  Aerospace 

Ground  Equipment,  General 
Requirements  for 

MIL-A-8421F 

25  Oct  74 

Notice  1,  28  May  87 

Air  Transportability  Requirements, 
General  Requirements  for 

MIL-S-8516E 

29  Sep  72 

Sealing  Compound,  Polysulfide 
Rubber,  Electric  Connectors  and 
Electric  Systems,  Chemically  Cured 

MIL-A-8625D 

30  Jun  85 

Anodic  Coatings,  for  Aluminum  and 
Aluminum  Alloys 

DOD-E-8983C 

29  DEC  77 

Electronic  Equipment,  Aerospace, 
Extended  Space  Environment, 
General  Specification  for 

MIL-F-14072C 

01  Jun  86 

Finishes  for  Ground  Electronic 
Equipment 

MIL.S-19500G 

22  Sep  86 

Supplement  1, 

11  Mar  85 

Supplement  IB, 

24  Aug  87 

Amendment  1, 

25  Aug  87 

Semiconductor  Device,  General 
Specification  for 

MIL-S-23586E 

10  Jul  87 

Sealing  Compound,  Electrical, 
Silicone  Rubber,  Accelerator 
Required 

MIL-C-28748A 

04  Feb  85 

Supplement  1 

Connector,  Electrical,  Rectangular, 
Rack  and  Panel,  Solder  Type  and 
Crimp  Type  Contacts,  General 

Specification  for 
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MIL-M-38510H 

12  Feb  88 

Supplement  1, 

08  Mar  88 

Amendment  1, 

31  Aug  88 

Microcircuit,  General  Specification 
for 

MIL-C-38999H 

30  Sep  86 

Supplement  1 

Connector,  Electrical,  Circular, 
Miniature,  High  Density,  Quick 
Disconnect  (Bayonet,  Threaded, 
and  Breech  Coupling),  Environ¬ 
ment  Resistant,  Removable  Crimp 
and  Hermetic  Solder  Contacts, 
General  Specification  for 

MIL-C-55302E 

09  Apr  86 

Connectors,  Printed  Circuit 
Subassembly  and  Accessories 

MIL-I.81550C 

14  Jul  83 

Insulating  Compound,  Electrical, 
Embedding,  Reversion,  Resistant 
Silicon 

MIL-S-81733C 

13  Mar  80 

Sealing  and  Coating  Compound, 
Corrosion  Inhibitive 

DOD-W.83575A 

22  DEC  77 

Wiring  Harness,  Space  Vehicle, 
Design  and  Testing,  General 
Specification  for 

MlL-S-83576 

01  Nov  74 

Solar  Cell  Arrays,  Space  Vehicle, 
Design  and  Testing,  General 
Specification  for 

MIL-A-83577B 

01  FEB  88 

Assemblies,  Moving  Mechanical, 
for  Space  and  Launch  Vehicles, 
General  Specification  for 

DOD-E-83578A 

15  OCT  87 

Explosive  Ordnance  for  Space 
Vehicles,  General  Specification 
for 

MIL-C-83723D 
27  Dec  77 
Supplement  1 


Connector,  Electrical  (Circular, 
Environment  Resisting)  Receptacles 
and  Plugs,  General  Specification  for 
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Other  Government  Activity  Specifications 
(TBS  -  include  any  Program  Specifications) 
STANDARDS: 


Federal 

(TBS) 

Military 

MIL-STD-171D 

29  Feb  80 

Finishing  of  Metal  and  Wood 
Surfaces 

MIL-STD-454K 

14  Feb  86 

Notice  1,  29  Aug  86 
Notice  2,  26  Feb  87 
Notice  3,  10  Sep  87 
Notice  4,  12  Feb  88 

Standard  General  Requirements 
for  Electronic  Equipment 

MIL-STD-721C 

12  Jun  81 

Definitions  of  Terms  for  Reliability 
and  Maintainability 

MIL-STD-889B 

21  Nov  79 

Notice  1,  04  Mar  79 
Notice  2,  04  Mar  88 

Dissimilar  Metals 

MIL-STD-1246B 

04  Sep  87 

Product  Cleanliness  Levels  and 
Contamination  Control  Program 

MIL-STD-1250 

31  Mar  67 

Corrosion  Prevention  and 
Deterioration  Control  in  Electronic 
Components  and  Assemblies 

MIL-STD-1472C 

31  DEC  74 

Notice  1,  01  Sep  83 
Notice  2,  10  MAY  76 
Notice  3,  17  MAR  87 

Human  Engineering  Design 

Criteria  for  Military  Systems, 
Equipment,  &  Facilities 
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MIL-STD-1474B 

18  Jun  79 

Notice  1,  10  Oct  84 

Notice  2,  20  Apr  84 

Noise-limits  For  Army  Materiel 

MIL-STD-1522A 

28  MAY  84 

Notice  1,  21  Dec  84 

Notice  2,  20  Nov  86 

Standard  General  Requirements 
for  Safe  Design  and  Operation  of 
Pressurized  Missile  and  Space 
Systems 

MIL-STD-1539 

73  AUG  01 

Electrical  Power,  Direct  Currenr 
Space  Vehicle  Design  Requirements 

MIL-STD-1540B 

10  OCT  82 

Notice  1,  31  Jul  89 

Test  Requirements  for  Space 
Vehicles 

MIL-STD-1541A 

31  DEC  87 

Electromagnetic  Compatibility 
Requirements  for  Space  Systems 

MIL-STD*1542A(USAF) 

01  MAR  88 

Electromagnetic  Compatibility 
(EMC)  and  Grounding  Requirements 
for  Space  System  Facilities 

MIL-STD-1547A 

01  DEC  87 

Electronic  Parts,  Materials,  and 
Processes  for  Space  and  Launch 
Vehicles 

MIL-STD-1568A 

24  Oct  79 

Materials  and  Processes  for 
Corrosion  Prevention  and  Control 
in  Aerospace  Weapon  Systems 

MIL-STD-1574A(USAF) 

15  Aug  79 

System  Safety  Program  for 

Space  and  Missile  Systems 

DOD-STD-1578B 

01  JAN  87 

Nickel-cadmium  Battery  Usage 
Practice  for  Space  Vehicles 

MIL-STD-1589C 

06  JUL  84 

JOVIAL  (J73) 

ANSI/MIL-STD-1815A 

22  Jan  83 

Ada  Programming  Language 
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(TBS) 

OTHER  PUBLICATIONS: 


Manuals 

(TBS) 

Regulations 

(TBS) 

(TBS) 

Handbooks 

MIL.HDBK-5E 

01  JUN  87 

Notice  1,  01  May  88 

Aerospace  Vehicle  Structures, 
Metallic,  Materials  and  Elements 
for 

MIL-HDBK-17A 

01  SEP  73 

Notice  1,  08  Jun  87 

Plastics  for  Aerospace  Vehicles  - 
Part  1,  Reinforced  Plastics 

MIL-HDBK-17A 

08  JUN  77 

Plastics  for  Aerospace  Vehicles  - 
Part  II,  Transparent  Glazing 
Materials 

Electrostatic  Discharge  Control 
Handbook  for  Protection  of 
Electrical  and  Electronic  Parts, 
Assemblies  and  Equipment 

MlL-HDBK-340  Application  Guidelines  for 

01  Jul  85  MIL-STD-1540B;  Test  Require- 

Notice  1,  31  Jul  89  ments  for  Space  Vehicles 


DOD-HDBK-263 
02  May  80 
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OTHER  GOVERNMENT  DOCUMENTS.  DRAWINGS,  AND  PUBLICATIONS 


FIPS  PUB  1  Code  for  Information  Interchange 

(Federal  Information  Processing  Standard; 
National  Bureau  of  Standards.  This 
document  is  the  same  as  ANSI-STD  X  3.4- 
1968.) 


SP-R-0022  Vacuum  Stability  Requirements  of 

Polymeric  Materials  for  Spacecraft 
Applications  (NASA  JSC) 

SAMTO  KB  S-100  Space  Transportation  System  Payload 

Ground  Safety  Handbook  (Joint  NASA/Air 
Force  document  designated  by  NASA  as 
KHB  1700.7) 


KHB  1700.7  Space  Transportation  System  Payload 

Ground  Safety  Handbook  (Joint  NASA/Air 
Force  document  designated  by  the  Air 
Force  as  SAMTO  HB  S-100) 

NHB  1700.7  Safety  Policy  and  Requirements  for  Pay- 

loads  Using  the  Space  Transportation 
System  (STS)  (NASA) 

JSC  07700  Space  Shuttle  System  Payload  Accommo¬ 

dations,  Vol  XIV,  (NASA  JSC) 


(Copies  of  specifications,  standards,  handbooks,  drawings,  and  publica¬ 
tions  inquired  by  contracto's  in  connection  with  specified  acquisition 
functions  should  be  obtained  from  the  contracting  activity  or  as 
directed  by  the  contracting  officer.) 

2.2  NONGOVERNMENT  DOCUMENTS 

The  following  documents  of  the  exact  issue  shown  form  a  part 
of  this  specification  to  the  extent  specified  herein.  In  the  event  of 
conflict  between  the  documents  referenced  herein  and  the  contents  of 
this  specification,  see  Section  3.6. 


A-9 


SPEC  NUMBER  SS-01 
15  OCT  91 


APPENDIX  A 


SPECmCATIONS: 

(TBS) 

STANDARDS: 

AMERICAN  NATIONAL  STANDARDS  INSTITUTE 

ANSI  STD  X  3.4-1968  Code  for  Information  Interchange 

(Federal  Informatioii  Processing 
Standard;  National  Bureau  of 
Standards;  FIPS  PUB  1) 

Application  for  copies  should  be  addressed  to: 

American  National  Standards  Institute 
10  E.  40th  Street 
New  York.  NY  10016 

INSTITUTE  OF  ELECTRICAL  AND  ELECTRONICS  ENGINEERS 

ANSI/IEEE  Std  416-1978  IEEE  Standard 

Atlas  Test  Language 

Application  for  copies  should  be  addressed  to: 

Institute  of  Electrical  and  Electronics  Engineers,  Inc. 

345  E.  47th  Street 
New  York,  NY  10017 

DRAWINGS: 

(TBS) 

OTHER  PUBLICATIONS: 

(TBS) 

(Technical  society  and  technical  association  specifications  and 
standards  generally  are  available  for  reference  from  libraries.  They 
also  are  distributed  among  technical  groups  and  using  federal 
agencies.  The  contracting  officer  should  be  contacted  regarding  the 
availability  of  any  referenced  document  not  readily  available  from 
other  sources.) 
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SECTION  3 

SYSTEM  REQUIREMENTS 


3.1  DEFINITION 

3.1.1  System  Description.  This  system  (TBS  -  insert  state¬ 
ment  of  the  purpose  or  major  functions  of  the  system  and  identify 
other  systems  with  which  it  interfaces).  The  major  functional  areas 
within  the  system  include  operational  support  functions,  logistic 
support  functions,  computer  software  maintenance  functions,  training 
functions,  and  (TBS). 

3.1.2  System  Segments.  The  space  system  is  an  element  of  the 
(TBS  -  insert  program).  For  convenience,  the  system  has  been 
subdivided  into  the  following  major  system  segments: 

a.  Space  system  segment 

b.  Ground  terminal  system  segment 

c.  Data  reduction  system  segment 

d.  (TBS  -  other  system  segments) 

3.1.3  Specification  Tree.  The  specification  tree  for  the  system 
is  shown  in  Figure  3-1.  The  specification  tree  for  the  space  vehicle 
system  segment  is  shown  in  Figure  3-2.  (If  known  at  the  time  the 
system  specification  is  prepared,  the  subtier  configuration  items  in 
each  system  segment  also  would  be  identified.)  The  specification  tree 
for  the  space  vehicle  is  shown  in  Figure  3-3. 

3.1.4  Top-Levei  System  Functions 

3.1.4.1  Top-Leyel  System  Functional  Relationships.  The 
top-level  functional  flow  diagram  for  the  system  is  shown  in  Figure 
3-4.  A  more  detailed  functional  flow  diagram  for  the  system  is  shown 
in  Figure  3-5. 
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Program  Management 

Directive  | 

and 

System  Operational  | 
Requirement  Document 


Launch 
I  System 
Spec. 


I  I  r"  "I  I  I 

Wide-  On-  Satellite  Other 

j  Band  |  Orbit  |  Control  |  | System  | 

Commun.  Space  Network  Specs. 

(System  |  System  |  System  |  |  | 

Spec.  Spec.  Spec. 


Ground 

Terminal 

System 

Segment 

Spec. 


Space 

Vehicle 

System 

Segment 

Spec. 


Data 

Reduction 

System 

Segment 

Spec. 


Other 

System 

Segment 

Specs. 


Figure  3-1.  On-orbit  Space  System  Specification  Tree. 
(Interfacing  Systems  Shown  By  Dashed  Lines) 
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Figure  3-2.  Space  Vehicle  System  Segment  Specification  Tree. 
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Space 
Vehicle 
Cl  Spec. 


--  Propulsion  subsystem  Cls 
--  Thrust  vector  control  subsystem  Cls 
--  Reaction  control  subsystem  Cls 
--  Data  management  subsystem  Cls 
--  Computer  software  subsystm  Cls 
--  Electrical  power  subsystem  Cls 
--  Guidance  and  navigation  subsystem  Cls 
--  Telemetry,  tracking,  and  command  subsystem  Cls 
••  Structural  subsystem  Cls 
--  Thermal  control  subsystem  Cls 
-  Payload  subsystem  Cls  (if  appropriate) 


Figure  3-3.  Space  Vehicle  Specification  Tree. 


System 

Inputs 


System 

Outputs 

-Operational  support  functions - 

Logistic  support  functions - 

Computer  software  maintenance  functions - 

Training  functions -  - 

(TBS)  - 


Figure  3-4.  Top-level  Functional  Flow  for  the  System. 
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3. 1.4.2  Description  of  System  Functions.  (TBS  -  List  the 
major  system  functions  and  insert  a  subparagraph  for  each  specific 
function  named  that  describes  the  function,  its  purpose,  and  identifies 
its  inputs  and  outputs  to  the  extent  known.  The  states  and  modes  in 
which  each  function  operates  also  shall  be  described  to  the  extent 
known.) 

3.1.4.3  Missions.  (TBS) 

3. 1.4.4  Threat.  The  system  is  subject  to  the  threat  described  in 
Appendix  A. 

3.1.5  System  States  and  Modes.  After  initial  deployment,  the 
system  may  be  commanded  or  be  sequenced  through  the  following 
states  and  modes: 
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a.  Prelaunch  state 

1.  Ground  storage  mode 

2.  Ground  transportation  mode 

3.  Launch  pad  assembly  mode 

4.  Prelaunch  countdown  mode 

b.  Launch  state 

1.  Launch  mode 

2.  Orbit  injection  mode 

c.  Operational  state 

1.  Standby  mode,  ground  equipment 

2.  Standby  mode,  on-orbit  equipment 

3.  Normal  operational  mode 

4.  Eclipse  operational  mode,  on-orbit  equipment 

5.  Maintenance  mode,  ground  equipment 

6.  Maintenance  mode,  computer  software 

7.  Maintenance  mode,  on-orbit  equipment 

d.  Space  vehicle  recovery  state 

1.  Space  vehicle  reentry  mode 

2.  Space  vehicle  landing  mode 

3.  Space  vehicle  refurbishment  mode 

e.  (TBS  -  Other) 

3.1.6  Operational  and  Organizational  Concents.  The  system 
supports  a  space  vehicle  launch  and  possible  retrieval  using  the  Space 
Transportation  System  (STS)  or  a  launch  using  the  (TBS)  expendable 
launch  vehicle.  On-orbit  operations  are  planned  to  be  controlled  from 
the  mission  control  center  (MCC)  located  (TBS)  and  remote  tracking 
stations  located  (TBS). 

3.1.6.1  STS  Operational  Concent.  The  following  STS  opera¬ 
tional  concept  is  supplied  as  a  guide  for  use  in  the  system  design  and 
for  the  preparation  of  operational  plans  and  test  plans. 

3.1.6.1.1  STS  Prelaunch.  The  space  vehicle  would  be  trans¬ 
ported  directly  to  the  launch  base  where  final  space  vehicle  prepara¬ 
tions  and  checkout  would  be  accomplished  at  the  Payload  Preparation 
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Room  of  the  STS  launch  facility.  Final  intersegment  and  launch  verifi¬ 
cation  tests  would  be  accomplished  after  space  vehicle  and  associated 
equipment  installation  in  the  STS  and  prior  to  launch. 

3.1.6.1.2  STS  Launch.  During  STS  ascent  to  the  parking  orbit, 
various  space  vehicle  subsystems  or  system  equipments  may  be 
powerrd  on  or  turned  off  in  order  to  provide  protection  from  the  STS 
environments  or  to  comply  with  STS  safety  requirements.  Space 
vehicle  telemetry  to  monitor  vehicle  status  would  be  provided  to  the 
STS  for  monitoring  and  retransmission  (in  real  time  or  playback)  to 
the  ground  monitoring  stations. 

3.1.6.1.3  STS  Parking  Orbit  Operations.  While  the  space 
vehicle  is  attached  to  the  STS,  vehicle  telemetry  to  monitor  vehicle 
status  continues  to  be  provided  to  the  STS  for  monitoring  and  retrans¬ 
mission  (in  real  time  or  playback)  to  the  ground.  When  the  space 
vehicle  is  released  from  the  STS,  responsibility  for  monitoring  and 
control  would  be  transferred  to  the  ground  MCC.  The  STS  may  provide 
assistance  for  the  resolution  of  anomalies  when  requested  by  the  MCC. 
In  the  event  of  unsatisfactory  deployment  or  unsatisfactory  space 
vehicle  checkout,  the  STS  would  retrieve  the  vehicle  and  return  to  the 
launch  site. 


3. 1.6. 1.4  Space  Vehicle  Orbit  Injection.  After  release  by  the 
STS  and  successful  vehicle  checkout  and  appendage  deployment,  the 
vehicle  would  boost  itself  (or  would  be  boosted)  into  its  operational 
orbit  under  command  from  the  ground. 

3. 1.6.2  Expendable  Launch  Vehicle  Operational  Concent. 
When  the  use  of  an  expendable  launch  vehicle  is  planned,  the  follow¬ 
ing  operational  concept  is  the  guide  for  use  in  the  system  design  and 
for  the  preparation  of  operational  plans  and  test  plans. 

3. 1.6.2. 1  Prelaunch.  The  space  vehicle  would  be  transported 
directly  to  the  launch  base  where  final  vehicle  preparations  and 
checkout  would  be  accomplished  on  the  launch  vehicle  after  mating. 
Final  intersegment  and  launch  system  verification  tests  are 
accomplished  prior  to  launch. 

3.1. 6.2.2  Launch  and  Inieclion.  During  launch  and  injection  to 
the  operational  orbit,  the  various  vehicle  subsystems  may  be  powered 
on  or  turned  off  in  order  to  provide  protection  from  the  launch  and 
injection  environments  or  to  comply  with  other  specified  require¬ 
ments.  Space  vehicle  telemetry  to  monitor  vehicle  status  would  be 
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provided  during  launch  and  injection.  Transmission  using  the  launch 
vehicle  telemetry  may  satisfy  this  requirement  during  the  launch 
phase.  Space  vehicle  telemetry  transmission  to  ground  monitoring 
stations  would  be  used  to  the  extent  practicable  during  the  injection 
phase.  After  release  by  the  booster  and  reception  of  appropriate 
ground  commands,  the  space  vehicle  would  deploy  appropriate  appen¬ 
dages  and  boost  itself  (or  would  be  boosted)  into  its  operational  orbit. 

3.1.63  On-orbit  Operational  Concent.  The  following  on-orbit 
operational  concept  is  supplied  as  a  guide  for  use  in  the  system  design 
and  for  the  preparation  of  operational  plans  and  test  plans. 

3.1.6.3.1  On-orbit  Tests.  The  initial  on-orbit  period  is  devoted 
to  a  complete  space  vehicle  checkout  and  the  calibration  and  perform¬ 
ance  verifications  of  the  payload(s).  The  space  vehicle  and  payload 
performance  verification  tests  may  be  repeated  at  appropriate  times 
during  the  operational  phase  of  the  mission. 

3.1.6.3.2  On-orbit  Operations.  The  space  vehicle  and  the 
applicable  payload  equipment  would  be  commanded  from  the  ground 
using  commands  transmitted  for  execution  in  real  time  and  by  com¬ 
mands  transmitted  and  stored  in  the  space  vehicle  for  subsequent  on¬ 
board  execution.  Protection  would  be  provided  in  the  space  vehicle  in 
the  event  of  inappropriate  commands  or  the  lack  of  commands,  i.e., 
the  space  vehicle  may  go  into  a  contingency  mode.  In  the  contingency 
mode,  the  vehicle  would  be  oriented  to  the  sun  and  configured  in  a 
protected  state  that  does  not  deplete  electrical  power.  In  the  contin¬ 
gency  mode,  the  vehicle  would  retain  telemetry  capabilities  to  facili¬ 
tate  fault  isolation  and  command  capabilities  required  to  return  to 
normal  operation  or  to  perform  a  controlled  space  vehicle  deorbit. 

3.1. 6.3.3  Mission  Completion.  At  the  completion  of  the  space 
vehicle  mission,  the  space  vehicle  would  be  either  deboosted  to  the 
STS  retrieval  orbit,  deorbited,  or  all  equipment  would  be  commanded 
off.  For  STS  retrieval,  the  space  vehicle  provides  space  vehicle  safety 
status  and  other  required  verification  data  to  the  STS.  Once  captured, 
the  space  vehicle  would  be  stored  in  the  STS  payload  bay.  At  the 
appropr  ite  point  in  the  orbit,  the  STS  would  deorbit  and  return  to 
Vandenberg  Air  Force  Base.  After  STS  rollout  and  safing,  the  STS 
would  be  brought  to  the  STS  Processing  Facility,  where  the  space 
vehicle  would  be  removed  and  processed  for  transportation  to  the 
factory.  In  the  event  of  an  unsuccessful  STS  retrieval  of  the  space 
vehicle,  the  space  vehicle  would  be  deorbited.  Also,  in  the  event  of  an 
aborted  STS  launch,  it  would  be  at  this  point  that  the  space  vehicle 
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could  be  recycled  back  to  the  launch  pad  or  to  the  factory.  (Where 
mission  completion  consists  of  commanding  all  equipment  off,  that 
should  be  specified  instead  of  retrieval  or  deorbit.  Where  it  is 
planned  that  a  space  vehicle  launched  using  an  expendable  launch 
vehicle  may  be  retrieved  or  serviced  using  the  STS,  specific  on-orbit 
or  mission  completion  requirements  would  be  described.) 

3.2  CHMACTERISTICS 

3.2.1  Pcrf.orjna.ii£.e _ Charactcristii;s 

3.2.1.1  Performance  Requirements  for  Each  System  State 


3.2.1. 1.1 

Performance 

Reouirements 

for 

Prelaunch 

State.  (TBS) 

3.2.1.1.2 

Performance 

Reouirements 

for 

Launch 

State.  (TBS) 

3.2.1. 1.3 

Performance 

Reouirements 

for 

Onerational 

State.  (TBS) 

3.2.1.1.4 

Pertormance... 

Reouirements 

for 

Snace  Vehicle 

Recovery  State.  (TBS) 

3.2.1.2  Endurance.  The  ground-based  elements  of  the  system 
shall  have  a  design  service  life  of  20  years  with  an  operations  duty 
period  of  24  hours  per  day,  7  days  per  week.  The  elements  of  the 
system  associated  with  the  STS  Orbiter  operations  shall  have  a  design 
service  life  of  15  years.  The  on-orbit  design  life  of  the  space  vehicle, 
as  may  be  limited  by  mechanical  wearout,  battery  life,  solar  array  life, 
or  the  exhaustion  of  expendables,  shall  be  no  less  than  5  years.  The 
design  of  the  space  vehicle  shall  be  such  that  space  vehicle  storage, 
under  controlled  conditions,  may  be  planned  for  as  long  as  4  years. 

The  design  service  life  of  the  space  vehicle  shall  be  10  years  based  on 
the  sum  of  the  allowed  storage  time,  prelaunch  checkout  time,  launch 
and  injection  time,  on-orbit  time,  recovery  time,  and  contingency  time. 
(TBS) 

3.2.1.3  QjjLfiX 

3.2.2  SLYSlem _ Capability _ Relationships 
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3.2.2.1  Reference  Timelines.  (TBS) 

3.2.2.2  Descrintion.  (TBS) 

3.23  External  Interface  Requirements.  The  interfaces  of  the 
on-orbit  space  system  with  other  elements  of  the  space  program  are 
identified  in  Figure  3-6.  Detailed  quantitative  interface  requirements 
are  stated  in  subsequent  paragraphs. 

3.2.3.1  Description  ot  External  Interface  with 

Launch  System.  (TBS) 

3.2.3.2  Description  of  External  Interface  with 

Communication  System.  (TBS) 

3.2.3.3  Description  of  External  Interface  with 

Satellite  Control  Network.  (TBS) 

3.2.3.4  Description  of  External  Interface  with 

Other  Systems.  (TBS) 

3.2.4  Physical  Characteristics 

3.2.4.1  Protective  Coatings.  The  finishes  used  shall  be  such 
that  completed  devices  shall  be  resistant  to  corrosion.  The  design  goal 
shall  be  that  there  would  be  no  destructive  corrosion  of  the  completed 
devices  when  exposed  to  moderately  humid  or  mildly  corrosive  envi¬ 
ronments  that  could  inadvertently  occur  while  unprotected  during 
manufacture  or  handling,  such  as  possible  industrial  environments  or 
sea  coast  fog  that  could  be  expected  prior  to  launch.  Destructive  cor¬ 
rosion  shall  be  construed  as  being  any  type  of  corrosion  which  inter¬ 
feres  wit.  meeting  the  specified  performance  of  the  device  or  its 
associated  parts.  Protective  methods  and  materials  for  cleaning,  sur¬ 
face  treatment,  and  applications  of  finishes  and  protective  coating 
shall  be  in  accordance  with  MIL-F-7179.  Chromium  plating  shall  be  in 
accordance  with  QQ-C-320.  Nickel  plating  shall  be  in  accordance  with 
QQ-N-290.  Corrosion  protection  of  magnesium  shall  be  in  accordance 
with  MIL-M-3171.  Coatings  for  aluminum  and  aluminum  alloys  shall 
be  in  accordance  with  MIL-C-5541  or  MIL-A-8625. 

3.2.4.1.1  Space  Vehicle  Equipment  Protective  Coatings. 
Neither  cadmium  nor  zinc  coatings  shall  be  used. 
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Figure  3-6.  Major  External  System  Interfaces. 
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3.2.4.1.2  Ground  Eauipinent  Protective  Coatings.  Finishes 
for  ground  electronic  equipment  shall  be  in  accordance  with  MIL-F- 
14072C.  (TBS) 

3.2.4.2  Mass  and  Size  Properties 


3.2.4.2.1  Space  Vehicle  Size  Properties.  The  coordinate 
system  definitions  and  envelope  constraints  shall  be  as  shown  in 
Figure  (TBS).  For  the  spacebome  equipment,  the  envelope  constraints 
shall  be  based  upon  the  dynamic  envelopes  encountered  during 
factory  assembly,  system  test,  uansportation,  integration  with  the 
booster,  maintenance,  launch,  and  other  phases  of  operations.  (TBS) 


3.2.4.2.2  Space  Vehicle  Mass  Properties.  The  mass  proper¬ 
ties  of  the  space  elements  shall  be  determined  as  required  to  assure 
vehicle  performance,  stability,  and  control  (TBS).  The  weight  of  the 
space  vehicle  shall  not  exceed  (TBS).  The  weight  of  the  space  elements 
shall  be  controlled  for  the  preservation  of  performance  margins  and  as 
a  control  of  other  mass  properties.  The  recommended  weight 
contingency  for  space  elements  is  as  follows; 


a.  Preliminary  design 

New  equipment  20  percent 

GFE  and  existing  equipment  5  percent 


b.  Critical  design 

New  equipment 

GFE  and  existing  equipment 


10  percent 
3  percent 


c.  Final  design 

New  equipment 

GFE  and  existing  equipment 


5  percent 
2  percent 


3.2.4.2.3  Ground  Equipment  Size  Properties.  Ground 
elements  of  the  system  shall  be  assembled  into  racks  and  enclosures 
that  conform  to  Requirement  55  of  MIL-STD-454.  Racks  joined  or 
grouped  together  shall  have  the  same  dimensions.  Equipment  and 
attachment  cables  intended  for  rack  mounting  shall  conform  to  the 
rack  dimensions.  Front  panels  of  equipment  shall  combine  to  provide 
a  continuous  front  face  of  the  rack. 


Dimensions  of  the  largest  ground  elements  of  the  system  intended 
to  be  transported  as  a  unit  shall  not  exceed  2.59  x  2.62  x  13.7  meters 
(8.5  X  8.6  X  45  feet)  (WxHxL).  Each  item  of  assembled  equipment,  less 
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all  undercarriage  and  planned  removable  elements,  shall  not  exceed 
the  size  limits  of  MIL-A-8421  for  C130  aircraft,  C141  aircraft,  or  C5-A 
aircraft  using  the  463L  cargo  system. 

3.2.4.2.4  Ground  Equipment  Mass  Properties.  The  mass  and 
size  properties  of  ground  elements  of  the  system  shall  be  consistent 
with  their  intended  application.  The  weight  of  hand-carried  equip¬ 
ment  shall  not  exceed  (TBS).  The  center  of  gravity  and  tiedowns  of 
ground  equipment  shall  be  such  that  probable  seismic  activity  will  not 
cause  the  equipment  to  upset. 

The  weight  of  ground  elements  shall  be  controlled  to  avoid  excess¬ 
ive  floor  loading  for  fixed  equipment  and  excessive  road  loading  for 
mobile  equipment.  Equipment  shall  not  exceed  a  floor  loading  of  900 
kilograms  per  square  meter  (184  pounds  per  square  foot).  Each  item 
of  assembled  equipment,  less  all  undercarriage  and  planned  remov¬ 
able  elements,  shall  conform  to  the  weight  limits  of  MIL-A-8421  for 
Cl 30  aircraft,  C141  aircraft,  or  C5-A  aircraft  using  the  463L  cargo 
system. 

3.2.4.3  Power 

3.2.4.3.1  Space  Vehicle  Internal  Power.  Space  vehicles  and 
experiments  shall  be  designed  to  operate  from  a  28  ±  6  volt  dc,  two- 
wire,  single-point  negative  grounded  power  subsystem  conforming  to 
MIL-STD-1539.  Nickel-cadmium  battery  usage  shall  be  in  accordance 
with  MIL-STD-1578. 

3.2.4.3.2  Space  Vehicle  External  Power.  Unless  otherwise 

specified,  space  vehicles  undergoing  checkout  shall  be  operated  from  a 
28+2  volt  dc,  two-wire,  single-point  negative  grounded  external 
power  subsystem.  The  primary  electrical  power  supplied  to  the 
system  equipment  mounted  in  the  STS  Orbiter  shall  be  (TBS). 

3.2.4.3.3  Ground  Equipment  External  Power.  The  primary 
electrical  power  supplied  to  the  ground-based  elements  of  the  system 
shall  be  (TBS). 

3.2.4.4  Survivability.  (TBS) 

3.2.4.5  Other.  (TBS) 

3.2.5  System  Quality  Factors 
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3.2.5.1  Reliability.  The  probability  of  mission  success  for  the 
nominal  mission  life  of  the  space  vehicle  and  experiments  shall  be  at 
least  0.95.  The  probability  of  mission  success  shall  include  consider¬ 
ation  of  any  potential  failures  in  associated  ground  operations,  such  as 
commanding,  that  might  not  be  corrected  in  time  to  avoid  an  impact 
on  the  space  equipment.  However,  failures  due  to  government- 
furnished  equipment  (GFE)  power  and  GFE  communications  are  exclu¬ 
ded  from  the  consideration.  The  reliability  allocations  shall  assure 
that  the  overall  mission  reliability  requirements  are  met,  considering 
the  most  severe  extremes  of  storage,  transportation,  testing,  and 
operations.  The  system  mean  time  between  failures  shall  be  evalu¬ 
ated  in  terms  of  events  and  usage  cycles  that  occur  during  a  typical 
service  life  cycle. 

3.2.5.1.1  Mean  Time  Between  Failures.  System  design  shall 
be  based  on  meeting  the  system  reliability  requirements  as  verified 
by  the  mean  time  between  failures  for  the  system  as  analytically 
determined  for  the  elements  of  the  system  for  each  operating  mode. 
The  mean  time  between  failures  is  as  defined  in  MIL-STD-721.  Piece 
part  or  component  failure  rates  obtained  from  actual  usage  data  shall 
be  used  where  available.  Failure  rates  estimated  from  standard  data 
sources  evaluated  at  anticipated  operating  conditions  shall  be  used 
when  data  under  actual  usage  are  nonexistent  or  inadequate.  Failure 
rates  shall  include  failures  attributable  to  computer  software 
problems. 

3.2.5.1.2  Redundancy.  Redundancy  to  eliminate  single  point 
failure  modes  may  be  incorporated  to  meet  the  reliability  require¬ 
ments,  unless  the  addition  of  the  redundancy  actually  reduces  overall 
reliability  due  to  the  added  complexity.  For  designs  that  switch 
redundant  units,  components,  or  subassemblies  autonomously,  or  by 
command,  the  failure  rates  for  the  switching  circuits,  and  for  the 
redundant  equipment  while  in  the  off-line  mode,  shall  be  appropri¬ 
ately  included  in  the  reliability  determination.  Where  practicable, 
provisions  shall  be  incorporated  to  verify  the  operation  of  all  switch- 
able  redundant  paths  without  disassembly. 

3.2.5.1.3  Space  Vehicle  Reliability.  Space  vehicle  design  shall 
be  based  on  meeting  the  system  reliability  requirements  as  verified 
by'  reliability  analyses  and  failure  mode  effects  and  criticality  analy¬ 
ses  conducted  on  the  space  vehicle  to  the  piece  part  level.  The  design 
of  space  equipment  shall  be  such  that  a  failure  in  one  component  shall 
not  propagate  to  other  components.  Where  practicable,  the  space 
vehicle  shall  be  capable  of  detecting  malfunctions  while  in  orbit  and 
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automatically  initiating  protective  measures  to  avoid  catastrophic  loss 
of  the  space  experiment  or  of  the  host  space  vehicle. 

The  space  vehicle  probability  of  survival  curve  shall  be  repre¬ 
sented  by  its  equivalent  Weibull  function: 

R(t)  =  e-(‘/alpha)**‘® 

where  alpha  =  scale  parameter 
beta  =  shape  parameter 

The  space  vehicle  probability  of  survival  for  the  nominal  service 
life  shall  be  at  least  O.S,  assuming  the  probability  of  launch  success  to 
be  at  least  0.98.  The  space  vehicle  probability  of  survival  shall 
include  consideration  of  any  potential  failures  in  associated  ground 
operations,  such  as  commanding,  that  might  not  be  corrected  in  time 
to  avoid  an  impact  on  the  space  vehicle. 

3.2.5.1.4  Failure  Tolerance  of  Pavloads  Using  the  STS.  The 
payloads  using  the  STS  shall  tolerate  a  minimum  number  of  credible 
failures  and  operator  errors  associated  with  hazardous  functions.  The 
criterion  that  applies  depends  upon  the  category  of  the  hazardous 
event  that  occurs  when  the  loss  of  a  function  or  inadvertent  occur¬ 
rence  of  a  function  results  in  a  hazardous  event. 

3.2.5. 1.4.1  Critical  Hazards.  A  critical  hazard  occurs  where  the 
potential  result  is  damage  to  STS  equipment  or  where  the  use  of 
contingency  or  emergency  procedures  is  required.  A  function  that 
could  result  in  a  critical  hazard  shall  be  controlled  by  two  independent 
inhibits  whenever  the  hazard  potential  exists.  When  required,  these 
inhibits  may  be  monitored  by  the  Orbiter  flight  crew  or  the  ground  in 
near  real  time.  For  deployable  payloads,  monitoring  and  safing  of  the 
two  inhibits  are  not  required  when  both  inhibit  power  and  control 
circuits  for  the  function  are  connected  to  a  bus  that  is  not  energized 
until  the  payload  reaches  a  safe  distance  from  the  Orbiter. 

3.2.5. 1.4.2  Catastrophic  Hazards.  A  catastrophic  hazard 
occurs  where  the  potential  result  is  personnel  injury  or  loss  of  the 
Orbiter,  ground  facilities,  or  STS  equipment.  A  function  that  could 
result  in  a  catastrophic  hazard  shall  be  controlled  by  a  minimum  of 
three  independent  inhibits  whenever  the  hazard  potential  exists.  One 
of  these  inhibits  shall  preclude  operation  by  RF  command.  Monitoring 
and  safing  of  the  three  inhibits  which  prevent  the  occurrence  of  a 
catastrophic  function  are  not  required  when  both  the  inhibit  power 
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and  control  circuits  are  connected  to  z  bus  that  is  not  energized  until 
the  payload  reaches  a  safe  distance  from  the  Orbiter.  When  the 
function  power  bus  or  control  circuits  are  powered  before  achieving  a 
safe  distance  from  the  Orbiter,  monitoring  shall  be  available  to  verify 
that  at  least  two  of  the  three  inhibits  are  in  place.  Monitoring  of  these 
inhibits  shall  be  available  to  the  launch  site  when  necessary  to  assure 
safe  ground  operations. 

3.2.5. 1.5  Ground  Equipment  Reliability.  Ground  equipment 
design  shall  be  based  on  meeting  the  system  reliability  requirements 
as  verified  by  failure  mode  effects  and  criticality  analyses  conducted 
on  ground  equipment  to  the  level  required  to  identify  all  single-point 
failure  modes  or  component  redundancy  requirements  for  the  ground 
equipment. 

3.2.5.1.5.1  Ground  Equipment  Fault  Tolerance.  All  subsys¬ 
tems  which  support  the  real-time  Range  Safety  function  (e.g.  subsys¬ 
tems  of  communications,  command  and  control,  and  timing)  shall  be 
fully  redundant  and  designed  in  accordance  with  the  fault-tolerant 
concepts  outlined. 

3.2.5.1.5.2  Ground  Eauipmenf  and  Software  Inter¬ 
dependent  Concent.  Fault-tolerant  responsibility  shall  be  assigned 
jointly  to  both  the  hardware  and  the  softwar*'.  Failure  control  func¬ 
tions  shall  be  shared  between  hardware  and  software  in  an  interde¬ 
pendent  manner  to  ensure  that  no  single  failure  could  prevent  the 
Range  Safety  Officer  from  successfully  transmitting  Range  Safety 
command(s)  to  a  space  vehicle  during  its  launch  phase. 

3.2.5.1.5.3  Nonoperational  Ground  Equipment Rcliabilily- 

Nonoperational  ground  equipment  is  ground  equipment  that  is  used 
off  line  in  such  areas  as  transportation,  maintenance,  or  training  and  is 
not  required  during  launch  or  on-orbit  operations.  Nonoperational 
ground  equipment  reliability  shall  be  based  on  meeting  a  mean  time 
between  failure  that  is  so  large  that  failures  would  not  be  expected  to 
interfere  with  the  functional  application  of  the  items. 

3.2.5.2  Maintainability 

3.2.5.2.1  Maintainability  of  Space  Vehicle  Equipment. 
Unless  maintenance  or  servicing  in  space  is  specifically  stated  as  a 
program  requirement,  space  vehicles  and  experiments  shall  be 
designed  so  as  to  not  require  any  scheduled  maintenance,  repair,  or 
servicing  during  their  service  life.  The  design  shall  incorporate  test 
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and  telemetry  points  to  allow  verification  of  functional  performance. 

The  design  shall  accommodate  easy  installation  and  replacement  of 
major  components  during  factory  assembly  and  of  explosive  ordnance 
devices,  batteries,  and  other  site  replaceable  items  at  the  launch  site 
when  they  are  mated  to  the  launch  vehicle.  Access  shall  be  provided 
to  those  test  plugs,  harness  break-in  points,  external  umbilical 
connections,  safe  and  arm  devices,  explosive  ordnance  devices, 
pressurant  and  propellant  fill  and  drain  valves,  and  other  devices  as 
might  be  required  for  prelaunch  maintenance,  alignment,  and 
servicing.  Alignment  references  for  critically  aligned  components 
shall  be  visible  directly  or  through  windows  or  access  doors. 

3.2.5.2.2  Maintainability  of  Ground  Eauipment.  To  the  extent 
practicable,  the  ground  elements  of  the  system  shall  be  based  on  high 
reliability  designs  that  minimize  scheduled  maintenance  or  repair  during 
their  service  life.  The  designs  shall  use  modular  construction  and  line- 
replaceable  units,  where  practicable,  to  accommodate  easy  installation 
and  replacement  of  major  subassemblies,  components,  and  other  rep¬ 
laceable  items.  Equipment  designs  shall  provide  easy  accessibility  to 
line-replaceable  units  in  order  to  minimize  the  mean  time  to  restore. 

The  equipment  shall  be  designed  to  provide  both  fault  detection  and 
fault  isolation  capabilities.  The  designs  shall  incorporate  built-in  test 
features,  self-test  features,  test  points,  and  telemetry  points  as  required 
to  allow  rapid  verification  of  functional  performance.  The  built-in  test  or 
self-test  capabilities  shall  be  capable  of  detecting  99  percent  of  equip¬ 
ment  faults.  The  equipment  shall  include  built-in  test  or  self-test  capa¬ 
bility  for  fault  isolation  to  a  single  line-replaceable  unit  95  percent  of  the 
time  and  to  a  maximum  of  two  line-replaceable  units  99  percent  of  the 
time.  Access  shall  be  provided  to  those  test  plugs,  harness  break-in 
points,  and  other  devices  as  might  be  required  for  maintenance,  align¬ 
ment,  and  servicing.  Alignment  references  for  critically  aligned  com¬ 
ponents  shall  be  visible  directly  or  through  windows  or  access  doors. 

Equipment  designs  shall  support  the  development  of  cost-effective 
operator-level  maintenance,  organizational-level  maintenance,  interme¬ 
diate-level  maintenance,  and  depot-level  maintenance. 

a.  Operator-Level  Maintenance.  Operator-level  maintenance  shall 
be  restricted  to  operational  tests  and  nontechnical  preventive 
maintenance  routines  which  are  suitable  for  accomplishment 
by  operator  personnel.  This  shall  include  self  tests,  simple 
fault  diagnosis  and  fault  isolation,  and  surface  cleaning  as 
required  by  environmental  conditions. 
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b.  Organizational-Level  Maintenance.  Organizational-level  main¬ 
tenance  shall  be  conducted  in  the  operational  environment 
using  contractor  personnel,  contractor-designated  spares, 
contractor-approved  maintenance  manuals,  and  contractor- 
approved  test  procedures.  Organizational-level  maintenance 
shall  consist  of  more  complex  fault  diagnosis  and  fault  isolation; 
removal  and  replacement  of  complete  assemblies  or  line- 
replaceable  units;  alignment;  and  calibration  necessary  to 
restore  the  failed  system  to  an  operational  condition. 

c.  Intermediate-Level  Maintenance.  Intermediate-level  main¬ 
tenance  shall  be  accomplis.oed  at  an  on-site  maintenance 
facility,  using  contractor  personnel,  contractor-designated 
spares,  contractor-approved  maintenance  manuals,  and 
contractor-approved  test  procedures.  Intermediate-level 
maintenance  shall  consist  of  preventive  maintenance  and  the 
repair  and  replacement  of  unserviceable  complete  assemblies 
or  line-replaceable  units.  Corrosion  control  shall  be 
accomplished  as  preventive  maintenance. 

d.  Depot-Level  Maintenance.  Depot-level  maintenance  shall  be 
accomplished  at  a  designated  maintenance  facility.  Depot  level 
maintenance  consists  of  all  maintenance  and  repairs  not 
accomplished  at  other  maintenance  levels.  Depot-level 
maintenance  shall  be  minimized. 

3.2.5.2.2.1  Mean  Time  to  Restore.  The  mean  time  to  restore  is 
as  defined  in  MIL-STD-721.  The  mean  time  to  restore  shall  include  fault 
isolation,  faulty  line-replaceable  unit  removal,  replacement  with  a  good 
line-replaceable  unit,  and  verification  of  operations.  At  the  organiza¬ 
tional  level,  the  mean  time  to  restore  shall  not  exceed  0.5  hour,  and  the 
maximum  time  shall  not  exceed  1.0  hour  at  the  90th  percentile.  At  the 
intermediate  level,  the  mean  time  to  restore  shall  not  exceed  1.0  hour, 
and  the  maximum  time  shall  not  exceed  2.0  hour  at  the  90th  percentile. 
Preventive  maintenance  shall  not  cause  total  down  time  but  shall  be 
scheduled  so  that  a  planned  partial  system  capability  is  available  at  all 
times. 

3.2.5.2.2.2  Maximum _ Downtime.  The  maximum  downtime  for 

ground  elements  of  the  system,  including  any  combination  of  preventive 
and  unscheduled  maintenance  time,  shall  be  no  greater  that  2.0  hours  at 
the  95th  percentile  of  the  downtime  distribution.  Ground  elements  of 
the  system  shall  be  considered  "down”  any  time  that  they  are  not 
capable  of  providing  the  scheduled  support. 


A-28 


APPENDIX  A 


SPEC  NUMBER  SS-01 
15  OCT  91 


3.2.5.2.2.3  Maintenance  and  Repair  Cycles.  All  preventive 
maintenance  shall  be  performed  on  a  scheduled  basis  to  prevent 
interference  with  opci  donal  support.  No  more  than  one  two-hour 
period  a  week  shall  be  required  for  preventive  maintenance  actions. 

3.2.5.2.2.4  Fault  Isolation.  The  following  fault  isolation 
capabilities  shall  be  provided: 

a.  An  expanding  and  collapsing  loop  test  capability  shall  be 
provided  to  assist  in  isolating  faults  to  the  line-replaceable 
unit.  Loop  tests  shail  be  controlled  from  the  operator  position. 

b.  Diagnostic  capability  and  routines  shall  be  provided  to  isolate 
faults  to  the  line-replaceable  unit  level.  Execution  of  diagnostic 
routines  shall  be  controlled  from  the  operator  position. 

c.  Built-in  test  features,  test  points,  signal  injection  capabilities, 
and  status  monitoring  features  shall  be  included  to  the 
maximum  extent  possible  on  off-the-shelf  equipment.  Newly 
developed  or  modified  equipment  also  shall  maximize  these 
capabilities.  Status  monitoring,  consistent  with  the  skill  level  of 
contractor  maintenance  personnel,  shall  be  provided  for  fault 
detection  and  isolation. 

3.2.5.3  Availability.  The  system,  when  efficiently  maintained, 
shall  provide  a  functional  availability  to  the  operator  position  at  any 
random  lime,  equal  u  or  greater  than  0.997.  The  system  availability 
requirement  does  not  include  the  GFE  power  or  GFE  communication 
networks. 

The  availability  of  the  system  is  defined  as  the  portion  of  the  total 
scheauled  support  time  during  which  the  system  can  provide  the  desired 
support.  The  availability  "A"  of  the  system  is  defined  mathematically  as: 

^  _ _ (Mean  time  between  failures) _ 

(Mean  time  between  failures)  +  (Mean  time  to  restore) 

The  mean  time  to  restor':  includes  the  mean  administrative  time 
associated  with  inaking  repairs  that  delay  the  completion  of  the  repairs, 
assuming  an  efficiently  maintained  system.  Efficiently  maintained 
means  that  the  repair  is  started  immediately  upon  system  failure,  and 
ail  necessary  replacement  parts,  components,  and  subsystems  are 
readily  available.  The  administrative  time  associated  with  making 
repairs  includes  the  time  to  obtain  the  necessary  parts  and  procedures. 
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3.2.5.4  Additional  Quality  Factors.  The  system  equipment  shall 
be  so  designed  and  constructed  that  no  fixed  part  or  assembly  shall 
become  loose,  no  moveable  part  or  assembly  shall  become  undesirably 
free  or  sluggish,  and  no  degradation  shall  be  caused  in  the  performance 
beyond  that  specified  for  the  system  equipment  during  operation  or 
after  storage. 

3.2.6  Environmental  Conditions.  To  provide  a  design  factor  of 
safety  or  margin,  the  various  system  CIs  and  their  components  shall  be 
designed  to  function  during  or,  if  appropriate,  following  exposure  to 
environmental  levels  that  exceed,  by  the  specified  margins,  the  maxi¬ 
mum  environmental  levels  predicted  for  all  applicable  operational  states 
and  modes  during  the  service  life  of  the  CIs. 

3.2.6. 1  Environmental _ Pgsjgn  Margins 

3.2.6.1.1  Environmental  Margins  for  Space  Equipment.  The 
required  environmental  design  margins  for  space  equipment  are  those 
specified  in  MIL-STD-1540.  Therefore,  the  required  environmental 
design  values  for  each  item  of  space  equipment  are  as  follows; 

a.  The  thermal  design  range  shall  be  10  degrees  C  beyond  the 

minimum  and  maximum  predicted  temperatures.  Where 

practicable,  each  component  shall  be  designed  to  operate 
continuously  within  an  ambient  temperature  range  of  at  least 
-34  degrees  C  to  +71  degrees  C.  To  prevent  generation  of  a 
possible  ignition  source,  the  temperature  of  any  part  exposed 
to  the  atmosphere  shall  not  exceed  178  degrees  C. 

b.  The  vibration  design  range  shall  be  6  dB  greater  than  the 
maximum  predicted  level  but  not  less  than  12  g’s  (rms). 

c.  The  acoustic  design  range  shall  be  6  dB  greater  than  the 
maximum  predicted  level  but  not  less  than  144  dB  overall. 

d.  The  shock  spectrum  design  range  shall  be  6  dB  greater  than  the 
maximum  predicted  level. 

3.2.6.1.2  Environmental  Margins  for  Ground  Equipment  or 

Mobile  Equipment.  No  environmental  design  margin  is  required  for 

ground  equipment  or  mobile  equipment.  The  design  values  shall  be  the 
minimum  and  maximum  predicted  as  applicable. 
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3.2.6.2  Environmental  Conditions  for  Space  EauiDment. 

Unless  otherwise  specified,  the  maximum  predicted  design  environments 
for  the  spaceborne  equipment  shall  be  determined  in  accordance  with 
the  definitions  in  MIL-STD-1540.  Where  practicable,  each  space  com¬ 
ponent  shall  be  designed  to  operate  continuously  within  an  ambient 
temperature  range  of  at  least  -34  degrees  C  to  +71  degrees  C  and  at 
ambient  pressures  between  sea  level  and  deep  space. 

3.2.6.2.1  Launch  Environments.  The  space  elements  shall  be 
designed  to  function  within  performance  specifications  after  or,  if 
appropriate,  during  exposure  in  the  launch  configuration  to  their  design 
environmental  levels.  These  design  environmental  levels  for  launch 
exceed  the  maximum  predicted  launch  environments  for  each  item  by 
the  environmental  design  margin. 

3.2.6.2.2  On-orbit  Environments.  The  space  elements  shall  be 
designed  to  function  within  performance  specifications  following  or,  if 
appropriate,  during  exposure  in  the  on-orbit  configuration  to  their 
design  environmental  levels.  These  design  environmental  levels  for  on 
orbit  exceed  the  maximum  predicted  on-orbit  environments  for  each 
item  by  the  environmental  design  margin. 

3.2.6.2.3  Grojind  Environments  for  Space  Eauipment.  These 
space  equipment  environments  are  those  associated  with  all  ground 
operations  except  testing,  including  storage,  transportation,  and  pre¬ 
launch  operations.  The  space  equipment  shall  be  designed  to  function 
within  performance  specifications  following  or,  if  appropriate,  during 
exposure  in  the  ground  configuration  to  environmental  levels  that 
exceed  the  maximum  predicted  ground  environments.  The  design  shall 
be  capable  of  sustaining  exposures  up  to  12  hours  in  humid  and  mildly 
corrosive  environments  that  could  occur  inadvertently  while  the  equip¬ 
ment  is  unprotected  during  manufacture  or  handling,  such  as  possible 
industrial  environments  or  sea  coast  fog  that  could  oe  expected  prior  to 
launch.  Relative  humidities  up  to  100  percent  can  be  encountered. 

Environmental  conditions  for  space  equipment  during  processing,  and 
during  storage  prior  to  shipment,  shall  be  within  the  following  limits: 

a.  Temperature:  21  degrees  C  +  20  degrees  C 

b.  Humidity:  50  percent  +  40  percent 
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Cleanliness  shall  be  maintained  during  processing,  storage,  and  trans¬ 
portation  using  appropriate  protective  containers  or  covers.  Tempera¬ 
ture  and  humidity  conditions  and  transportation  shock  exposure  shall  be 
monitored  subsequent  to  manufacture,  and  the  measured  levels  shall  be 
evaluated  against  the  acceptance  test  limits. 


3.2.6.2.4  Other  Environments  for  Space  Equipment.  (TBS) 


3.2.6.3  Environmental  Conditions  for  Ground  Equipment 


The  ground  equipment  shall  be  designed  to  function  within  performance 
specifications  following  or,  if  appropriate,  during  exposure  to  environ¬ 
mental  levels  that  exceed  the  maximum  predicted  ground  environments. 


3.2.6.3.1  Ground  Equipment  Natural  Environments 


3.2.6.3.1.1  Environmental _ Conditions  for  Ground  Equipment 

During  Storage  and  Transportation  (Nonoperating).  Ground 
equipment  shall  perform  within  its  specified  design  parameters  after 
exposure  in  the  storage  and  transport  configuration  (nonoperating)  to 
any  combination  of  the  following  storage  and  transportation  environ¬ 
mental  conditions: 

a.  Temperature.  The  ground  equipment  shall  withstand  an 
ambient  temperature  range  between  -55  degrees  C  and  -h68 
degrees  C  (-65  degrees  F  and  +155  degrees  F). 

b.  Relative  Humidity.  The  ground  equipment  shall  withstand  a 
relative  humidity  up  to  100  percent,  including  condensation 
due  to  temperature  changes. 

c.  Actinic  Radiation.  The  ground  equipment  shall  withstand 
actinic  radiation  as  encountered  in  the  tropics. 

d.  Barometric  Pressure.  The  ground  equipment  shall  withstand 
barometric  pressure  from  775  millimeters  of  mercury  to  520 
millimeters  of  mercury  (equivalent  to  altitudes  from  sea  level, 
0  meter  (0  foot),  to  altitudes  of  approximately  15,300  meters 
(50,000  feet). 

e.  Wind  Velocity.  Ground  equipment  shall  withstand  wind  con¬ 
ditions  of  240  kilometers  per  hour  (150  miles  per  hour). 
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f.  Salt  Atmosphere.  The  ground  equipment  shall  withstand  salt 
atmosphere  as  encountered  in  coastal  regions  and  during  ocean 
transport  (sea  water  in  equilibrium  with  air  at  a  pH  of  8.3  and 
overall  salinity  of  five  parts  per  thousand.) 

g.  Precipitation.  The  ground  equipment  shall  withstand  rainfall  of 
127  millimeters  per  hour  (5  inches  per  hour)  at  a  steady  wind 
of  64  kilometers  per  hour  (40  miles  per  hour).  Unsheltered 
equipment  also  shall  withstand  at  least  1440  pascals  (30 
pounds  per  square  foot)  of  loading  of  any  combination  of  ice, 
snow,  and  other  precipitation  without  permanent  deformation. 

h.  Sand  and  Dust.  The  ground  equipment  shall  withstand  sand 
and  dust  as  encountered  in  arid  regions  (0.18  to  0.30  milli¬ 
meters  diameter  sand  particles  and  0.0001  to  0.01  millimeters 
dust)  carried  by  winds  blowing  at  144  kilometers  per  hour  (90 
miles  per  hour). 

i.  Solar  Radiation.  The  ground  equipment  shall  withstand  the 
combined  effects  of  temperature  and  solar  radiation.  The 
equipment  design  shall  be  based  upon  a  temperature  of  +49 
degrees  C  (120  degrees  F)  and  the  full  impact  of  solar  radiation 
of  1136  watts  per  square  meter  (360  Btu  per  square  foot  per 
hour)  for  at  least  four  hours. 

3.2.6.3.1.2  Environmental  Conditions  for  Mobile  Ground 
Equipment  During  Deployment  (Nonoperating).  Mobile  ground 
equipment  shall  perform  within  its  specified  design  parameters  after 
exposure  during  deployment  at  an  operational  site  to  any  combination  of 
the  following  environmental  conditions: 

a.  Temperature.  The  mobile  ground  equipment  shall  be  capable 
of  being  deployed  at  an  ambient  temperature  of  0  degree  C  (32 
degrees  F)  to  38  degrees  C  (100  degrees  F). 

b.  Wind  Velocity.  The  mobile  ground  equipment  shall  be  capable 
of  being  deployed  under  wind  conditions  of  less  than  25 
kilometers  per  hour  (15  miles  per  hour). 

c.  Precipitation.  The  mobile  ground  equipment  shall  be  capable 
of  being  deployed  under  zero  precipitation  with  less  than  7.6 
centimeters  (three  inches)  of  snow  covering  the  ground. 
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d.  Deployment  Site.  The  mobile  ground  equipment  shall  be 
capable  of  being  deployed  at  unprepared,  clear  sites  with 
ground  slope  of  5  percent  or  less,  bearing  capability  of  718 
kilopascals  (15,000  pounds  per  square  foot)  or  greater,  and 
penetrable  soil  with  resistivity  of  1000  ohms  per  centimeter 
(2540  ohms  per  inch)  or  less. 

3.2.6.3.1.3  Mobile  Station  Handling  Shock  and  Vibration. 

The  equipment  shall  be  designed  to  withstand  or  be  protected  against 
the  random  and  sinusoidal  vibration  and  shock  environments  associated 
with  shipment  by  common  carrier  and  the  worst  probable  combination 
of  applicable  external  environments  defined  in  Paragraph  3.2.6. 

3.2.6.3.1.4  Environmental  Conditions  for  Ground  Equipment 
Operating  Within  an  Environmental  Shelter.  Most  ground  equip¬ 
ment  is  designed  for  operation  within  a  building  or  an  environmentally 
controlled  shelter.  The  air  conditioning  and  heating  shall  be  capable  of 
maintaining  the  building  or  shelter's  interior  temperature  in  the  range 
from  10  degrees  C  to  32  degrees  C  (61  degrees  F  to  90  degrees  F)  and  the 
relative  humidity  in  the  range  from  30  to  70  percent  under  the  worst 
probable  combination  of  operating  conditions.  Personnel  ventilation 
shall  conform  to  the  requirements  of  MIL-STD-1472.  However,  in  the 
event  of  failure  of  the  air  conditioning  or  heating,  the  system  equipment 
required  for  state-of-health  support  of  satellites  shall  be  capable  of 
continuing  operations,  with  only  minor  degradation  of  performance, 
while  operating  in  any  combination  of  the  following  environmental 
conditions: 

a.  Temperature.  The  ground  equipment  shall  withstand  an 
ambient  temperature  range  of  +0  degree  C  to  +49  degrees  C 
(+32  degrees  F  to  +120  degrees  F). 

b.  Relative  Humidity.  The  ground  equipment  shall  operate  in 
relative  humidity  up  to  100  percent,  including  condensation 
due  to  temperature  changes. 

c.  Barometric  Pressure.  The  ground  equipment  shall  operate 
within  barometric  pressure  from  775  millimeters  of  mercury  to 
520  millimeters  of  mercury  [equivalent  to  altitudes  of  from 
approximately  150  meters  (500  feet)  below  sea  level  to 
approximately  3000  meters  (10,000  feet)  above  sea  level]. 
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3.2.6.3.1.5  Environmental  Conditions  for  Ground  Equip, 
ment  Operating  Without  an  Environmental  Shelter.  Some 
ground  equipment,  such  as  antennas,  may  be  designed  to  operate 
without  an  environmentally  controlled  shelter.  Such  equipment  shall 
perform  within  its  speciHed  design  parameters  when  operating  in  any 
combination  of  the  following  environmental  conditions: 

a.  Temperature.  The  ground  equipment  shall  withstand  an 
ambient  temperature  range  of  -40  degrees  C  (-40  degrees  F) 
to  49  degrees  C  (+120  degrees  F)  (total  with  or  without  the 
presence  of  solar  radiation.) 

b.  Relative  Humidity.  The  ground  equipment  shall  operate  in 
relative  humidity  up  to  100  percent,  including  condensation 
due  to  temperature  changes. 

c.  Actinic  Radiation.  The  ground  equipment  shall  withstand 
actinic  radiation  as  encountered  in  the  tropics. 

d.  Barometric  Pressure.  The  ground  equipment  shall  operate 
within  barometric  pressure  from  775  millimeters  of  mercury 
to  520  millimeters  of  mercury  [equivalent  to  altitudes  of 
from  approximately  150  meters  (500  feet)  below  sea  level  to 
approximately  3000  meters  (10,000  feet)  above  sea  level]. 

e.  Wind  Velocity.  Ground  equipment  shall  operate  within 
specified  pointing  accuracies  and  survive  in  wind  conditions 
of  240  kilometers  per  hour  (150  miles  per  hour)  steady 
wind. 

f-  Salt  Atmosphere.  The  ground  equipment  shall  withstand  salt 
atmosphere  as  encountered  in  coastal  regions  and  during 
ocean  transport  (sea  water  in  equilibrium  with  air  at  a  pH  of 
8.3  and  overall  salinity  of  five  parts  per  thousand). 

g.  Precipitation.  The  ground  equipment  shall  withstand  rainfall 
of  127  millimeters  per  hour  (5  inches  per  hour)  at  a  steady 
wind  of  64  kilometers  per  hour  (40  miles  per  hour).  Unshel¬ 
tered  equipment  also  shall  withstand  at  least  1440  pascals 
(30  pounds  per  square  foot)  of  loading  of  any  combination  of 
ice,  snow,  and  other  precipitation  without  permanent 
deformation. 
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h.  Sand  and  Dust.  The  ground  equipment  shall  withstand  sand 
and  dust  as  encountered  in  arid  regions  (0.18  to  0.30  milli¬ 
meters  diameter  sand  particles  and  0.0001  to  0.01  milli¬ 
meters  dust)  carried  by  winds  blowing  at  144  kilometers  per 
hour  (90  miles  per  hour). 

i.  Solar  Radiation.  The  ground  equipment  shall  withstand  the 
combined  effects  of  temperature  and  solar  radiation.  The 
equipment  design  shall  be  based  upon  a  temperature  of  +49 
degrees  C  (120  degrees  F)  and  the  full  impact  of  solar  radia¬ 
tion  of  1136  watts  per  square  meter  (360  Btu  per  square  foot 
per  hour)  for  at  least  four  hours. 

3.2.6.3.2  Ground  Equipment  Induced  Environments 

3.2.6.3.2.1  Ground  Equipment  Acoustic  Noise  Environ¬ 
ment.  The  ground  equipment  shall  not  generate  steady-state  noise  in 
excess  of  65  dB(A)  nor  impulse  noise  in  excess  of  140  dB  as  measured 
inside  work  areas  that  may  be  occupied  by  operations  personnel. 
Steady-state  noise  and  impulse  noise  are  as  defined  in  MIL-STD-1474. 
Steady-state  noise  in  internal  areas  not  occupied  by  operations 
personnel,  but  which  may  be  visited  for  maintenance  or  repairs,  shall 
not  exceed  85  dB(A)  of  steady-state  noise,  nor  140  dB  of  impulse 
noise. 


3.2.6.3.2.2  Ground  Equipment  Nuclear  Explosion  Effects. 
The  ground  equipment  required  for  state-of-health  support  of  satel¬ 
lites  shall  be  protected  against  an  electromagnetic  pulse  (EMP 
phenomena  associated  with  nuclear  explosions)  with  the  character¬ 
istics  shown  in  Figure  TBS.  The  magnetic  field  in  ampere  turns  per 
meter  equals  the  electric  field  in  volts  per  meter  divided  by  377. 

3.2.6.3.2.3  Ground  Equipment  Environments  Induced  by 
Transportation 

3.2.6.3.2.3.1  firffluad _ Equipment  Environments  Induced  bv 

Air  Transportation.  In  the  air  transport  configuration,  the  ground 
equipment  and  its  associated  support  equipment  shall  be  capable  of 
withstanding  the  induced  dynamic  environments  and  loads  noted 
below: 


a.  C-141  aircraft:  per  Aerospace  Report  No.  TOR-0076(6892)-1 

b.  C-5A  aircraft:  per  Aerospace  Report  No. 
TOR-0076(6403-01)-2 
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c.  C-130  Aircraft:  TBD 

d.  Cargo  restraint  criteria:  per  MIL-A-8421 

3.2.6.3.2.3.2  Ground.  Equipment  Environments  Induced  bv 
Ground  Transportation.  The  ground  equipment  shall  be  designed  to 
withstand  or  be  protected,  in  the  ground  transport  configuration, 
against  the  random  and  sinusoidal  vibration  and  shock  environments 
associated  with  shipment  by  common  carrier  and  to  withstand  the 
environments  induced  by  travel  over  surfaces  having  roughness  as 
defined  in  U.S.  Army  Test  and  Evaluation  Command  Test  Operations 
Procedure  TOP  1-1-010  for  highways  and  gravel  roads  (Paragraphs  5.1 
and  5.2,  respectively). 

3.2.6.4  Environmental  Conditions  for  Other  Equip¬ 
ment.  (TBS) 

3.2.7  Transportability 

3.2.7.1  Equipment  Handling  Provisions.  Handling  tie-downs 
and  sling  points  shall  be  incorporated  in  the  design  of  the  equipment 
as  needed  to  optimize  transportability  and  complement  maintenance, 
warehousing,  and  other  handling  requirements. 

3.2.7.2  Electrostatic  Sensitive  Items.  Electrostatic  sensitive 
items,  such  as  most  electronic  assemblies  and  components  containing 
explosives,  shall  be  stored  and  transported  in  sealed  packages  using 
antistatic  wrapping  material.  The  antistatic  wrapping  material  used 
should  not  produce  nonvolatile  residues.  The  antistatic  wrapping 
material  shall  be  grounded  through  a  resistor  prior  to  removal.  The 
grounding  resistor  shall  have  a  value  between  100,000  ohms  and  1 
megohm. 

3.2.7.3  Space  Vehicle  Equipment  Transportability.  The 
space  equipment  shall  be  designed  for  ground  transportability  and  for 
air  transportability.  The  space  equipment  to  be  mounted  as  an  assem¬ 
bly  in  the  STS  shall  be  capable  of  being  transported  and  handled  in 
both  the  venical  and  horizontal  attitudes.  Attach  points  for  transpor¬ 
tation  and  handling  shall  be  provided  on  assemblies  weighing  more 
than  100  kilograms.  The  modes  of  transponation,  suppon,  and  types 
of  protective  covers  used  shall  be  chosen  to  assure  that  transponation 
and  handling  do  not  impose  thermal,  vibration,  acoustic,  or  shock 
environmental  conditions  which  exceed  those  imposed  by  operational 
modes  and  states. 
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3.2.7.4  Ground  EauiDinent  Transportability.  Ground 
equipment  shall  be  designed  to  be  handled  in  a  vertical  attitude. 

Attach  points  for  transportation  and  handling  shall  be  provided  on 
major  assemblies  weighing  more  than  100  kilograms.  Equipment  shall 
be  suitable  for  shipment  by  C-130  aircraft,  C-141  aircraft,  or  C5-A 
aircraft  using  the  463L  cargo  system;  or  by  military  land  vehicle. 

3.2.7.5  Mobile  Ground  Eouioment  Transportability.  Mobile 
ground  equipment  shall  be  designed  for  highways  and  improved 
cross-country  terrain  in  accordance  with  the  performance  and 
roadability  of  Type  HI  mobility.  Group  C  or  D,  of  MIL-M-8090.  The 
Mobile  Station  shall  be  designed  to  be  singly  towed  by  standard  fifth- 
wheel  48-inch  or  SO-inch  tractors  with  air  brakes.  The  mobile  ground 
equipment  shall  have  the  capability  to  make  complete  turns  to  the  left 
and  right  while  negotiating  a  slope  of  10  degrees,  with  the  towing 
vehicle  assuming  a  90-degree  angle  with  the  trailer.  The  towing  force 
required  to  move  the  mobile  ground  equipment  from  rest  shall  be 
comparable  to  that  required  for  a  commercial  vehicle  of  similar  size 
and  weight.  The  mobile  ground  equipment  shall  cause  load  bearing 
pressures  not  greater  than  718  Kilopascals  (15,000  pounds  per  square 
foot)  on  road  surfaces.  Mobile  ground  equipment  shall  comply  with 
Department  of  Transportation  (DOT)  and  SAE  requirements  and 
practices  for  operation  on  U.S.  highways  and  roads.  Mobile  ground 
equipment  ramp  capability  shall  be  consistent  with  the  constraints  of 
air  transportability  loading  and  unloading. 

3.2.8  Flexibility  and  Expansion.  System  flexibility  and  expan¬ 
sion  shall  be  provided  by  computer  resources  reserves  and  other  pro¬ 
visions  specified.  A  distinction  is  made  between  the  reserves  required 
for  operational  computer  resources  and  for  nonoperational  computer 
resources  (see  Paragraph  3.3.11). 

3.2.8. 1  Operational  Computer  Resource  Reserves.  A  distinc¬ 
tion  is  made  between  the  computer  resource  reserves  required  for 
space  elements  and  for  ground  elements  of  the  space  system.  Modifi¬ 
cation,  addition,  or  replacement  of  computer  resources  in  space  ele¬ 
ments  after  launch  is  not  planned.  Where  practicable,  the  reserve 
requirements  for  space  elements  shall  be  incorporated  into  the  base¬ 
line  design  so  that  equipment  modifications  are  not  required  to  satisfy 
the  reserve  requirements.  Where  required  computer  resource 
reserves  for  space  elements  are  allowed  through  modification,  addi¬ 
tion,  or  replacement,  but  arc  not  incorporated  into  the  baseline  design, 
the  design  of  the  computer  resources  and  of  the  space  vehicle  shall  be 


A-38 


APPENDIX  A 


SPEC  NUMBER  SS-01 
15  OCT  91 


such  that  equipment  modifications  may  be  readily  made  on  subse¬ 
quent  production  units  to  meet  the  growth  requirements.  Where 
required  computer  resources  reserves  for  ground  elements  of  the 
space  system  are  allowed  through  modification,  addition,  or  replace¬ 
ment,  but  are  not  incorporated  into  the  baseline  design,  the  design  and 
installation  of  the  ground  elements  shall  be  such  that  equipment  modi¬ 
fications  may  be  readily  made  after  the  initial  installation  to  meet  the 
growth  requirements. 

3.2.8.1.1  Computer  Resource  Reserves  for  Operational 
Space  Elements.  For  the  purposes  of  this  specification,  the  data 
processing  subsystems  of  the  operational  space  elements  are  defined 
to  comprise  all  computer  hardware,  software,  and  firmware  in  the 
space  vehicle(s),  including  all  interfacing  space  equipment  and  pay- 
loads  except  GFE  payloads  required  to  support  operational  missions. 
Note,  however,  that  the  worst  case  loading,  capacity,  throughput,  and 
access  rate  requirements  referred  to  in  this  specification  shall  con¬ 
sider  and  include  the  requirements  placed  upon  the  data  processing 
subsystems  of  the  space  elements  by  the  GFE  payloads,  as  well  as  the 
requirements  placed  upon  the  data  processing  subsystems  of  the  space 
elements  by  all  other  payload,  launch  vehicle,  spacecraft,  and  system 
interfaces. 

To  support  program  expansion  in  terms  of  additional  use  of  existing 
functions,  the  following  reserve  requirements  shall  be  provided  in  the 
operational  data  processing  subsystems  of  the  space  elements: 

a.  The  data  processing  subsystems  of  the  space  elements  shall 
be  capable  of  data  throughput  that  is  100  percent  greater 
than  that  required  to  satisfy  the  worst  case  data  processing 
requirements  that  could  jointly  load  the  data  processing 
subsystems  of  the  space  elements. 

b.  Under  the  additional  data  throughput  specified  (i.e.,  100 
percent  greater  than  that  required  to  satisfy  the  worst  case 
data  processing  requirements  that  could  jointly  load  the  data 
processing  subsystems  of  the  space  elements),  the  data 
processing  subsystems  of  the  space  elements  shall  meet  the 
originally  stated  functional  and  performance  computational 
requirements,  including  timing  requirements. 

In  addition,  the  components  of  the  data  processing  subsystems  of 
the  space  elements  shall  satisfy  the  computer  resource  reserve 
requirements  stated  in  the  following  subparagraphs.  For  the  purpose 
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of  the  following  subparagraphs,  the  term  "processor"  is  used  to  mean 
any  single  computer  onboard  a  space  vehicle,  whether  of  general- 
purpose  or  special-purpose  usage,  including  both  single  processor 
architecture  and  multiprocessor  architecture  computers.  Thus,  a 
processor  comprises  a  collection  of  computational  hardware,  including 
one  or  more  instruction  processing  units  with  their  associated  control 
units,  main  memory,  internal  busses,  and  circuitry,  that  function  as  a 
single  integrated  computational  device  (i.e.,  as  a  computer). 

3.2.8.1.1.1  Data  Processing  Subsystems _ Processor 

Reserves.  Within  the  processing  environment  of  the  data  processing 
subsystems  of  the  space  elements,  each  processor  shall: 

a.  Have  an  instruction  execution  rate  sufficient  to  process  a 
workload  that  is  100  percent  greater  than  the  worst  case 
processor  utilization  workload  that  could  load  that  processor. 

b.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  an 
instruction  execution  rate  sufficient  to  process  a  workload 
that  is  200  percent  greater  than  the  worst  case  processor 
utilization  workload  that  could  load  that  processor. 

Under  the  additional  workload  specified,  the  processor,  or  the  aug¬ 
mented  processor,  shall  meet  the  originally  stated  functional  and 
performance  computational  requirements,  including  timing  require¬ 
ments,  allocated  to  that  processor. 

3.2.8.1.1.2  Data  Processing  Subsystems  Primary  Memory 
Reserves.  Within  the  environment  of  the  data  processing  subsystems 
of  the  space  elements,  the  primary  memory  for  each  processor  shall: 

a.  Have  100  percent  greater  memory  capacity  than  the  worst 
case  memory  size  requirement  for  that  primary  memory 
component. 

b.  Have,  or  be  capable  of  having,  memory  added  (through 
modification,  addition,  or  replacement)  to  attain,  a  200 
percent  greater  memory  capacity  than  the  worst  case 
memory  size  requirement  for  that  primary  memory 
component. 
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c.  Have  a  memory  access  rate  sufficient  to  process  a  workload 
that  is  100  percent  greater  than  the  worst  case  memory 
access  workload  for  that  primary  memory  component. 

d.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  a  memory 
access  rate  sufficient  to  process  a  workload  that  is  200 
percent  greater  than  the  worst  case  memory  access  workload 
for  that  primary  memory  component. 

Under  the  additional  workloads  specified,  any  processor  accessing  a 
primary  memory,  or  augmented  memory,  shall  meet  the  originally 
stated  functional  and  performance  computational  requirements, 
including  timing  requirements  allocated  to  that  processor. 

3.2.8.1.1.3  Data  Processing  Subsystems  Peripheral  Data 
Storage  (Secondary  Memorvl  Reserves.  Within  the  environment 
of  the  data  processing  subsystems  of  the  space  elements,  each  periph¬ 
eral  data  storage  (secondary  memory)  component  shall: 

a.  Have  100  percent  greater  storage  capacity  than  the  worst 
case  storage  requirement  for  that  peripheral  data  storage 
component. 

b.  Have,  or  be  capable  of  having,  storage  added  (through 
modification,  addition,  or  replacement)  to  attain,  a  200 
percent  greater  storage  capacity  than  the  worst  case  storage 
requirement  for  that  peripheral  data  storage  component. 

c.  Have  an  access  rate  sufficient  to  process  a  workload  that  is 
100  percent  greater  than  the  worst  case  access  workload  for 
that  peripheral  data  storage  component. 

d.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  an  access 
rate  sufficient  to  process  a  workload  that  is  200  percent 
greater  than  the  worst  case  access  workload  for  that 
peripheral  data  storage  component. 

Under  the  additional  workloads  specified,  any  processor  accessing  a 
peripheral  data  storage  component,  or  augmented  peripheral  data 
storage  component,  shall  meet  the  originally  stated  functional  and  per¬ 
formance  computational  requirements,  including  timing  requirements, 
allocated  to  that  processor. 
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3.2.8.1.1.4  Data  Processing  Subsystems  Data  Transmission 
Media.  Within  the  environment  of  the  data  processing  subsystems  of 
the  space  elements,  each  data  transmission  medium  (e.g.,  local  or 
global  bus  or  channel)  shall; 


a.  Have  sufficient  capacity  to  support  data  throughput  that  is 
100  percent  greater  than  the  worst  case  data  throughput  that 
could  load  that  data  transmission  medium. 


b.  Have,  or  be  capable  of  being  augmented  (through  modifica¬ 
tion,  addition,  or  replacement)  to  have,  sufficient  capacity  to 
support  data  throughput  that  is  200  percent  greater  than  the 
worst  case  data  throughput  that  could  load  that  data  trans¬ 
mission  medium. 

c.  Have  a  data  access  rate  sufficient  to  process  a  workload  that 
is  100  percent  greater  than  the  worst  case  data  access  work¬ 
load  for  thai  data  transmission  medium. 


d.  Be  capable  of  attaining,  or  of  being  augmented  (through  mod¬ 
ification,  addition,  or  replacement)  to  attain,  a  data  access 
rate  sufficient  to  process  a  workload  that  is  200  percent 
greater  than  the  worst  case  data  access  workload  for  that 
data  transmission  medium. 


Under  the  additional  workloads  specified,  any  processor,  or 
augmented  processor,  accessing  the  data  transmission  medium,  or 
augmented  data  transmission  medium,  shall  meet  the  originally  stated 
functional  and  performance  computational  requirements,  including 
timing  requirements,  allocated  to  that  processor. 


3.2.8.1.1.5  Data  Processing  Subsystems  Software/Firm¬ 
ware.  The  software  and  firmware  in  the  data  processing  subsystems 
of  the  space  elements  shall  be  designed  (e.g.,  via  parameterization, 
appropriate  sizing  of  data  structures,  or  other  methods)  so  that 
utilization  of  the  computer  performance  reserves  specified  due  to 
additional  use  of  existing  functions  can  be  accomplished  without 
changes  in  the  software  or  firmware  logic.  Any  hardware  augmenta¬ 
tions  necessary  to  meet  the  expansion  requirements  shall,  where 
practical,  be  designed  so  that  the  software  and  firmware  in  the  data 
processing  subsystems  of  the  space  elements  are  upward  compatible 
with  the  implementation  of  those  augmentations. 
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3.2.8.1.1.6  Exceptions.  Exceptions  to  the  requirements  may  be 
granted  by  the  Contracting  Officer  for  specific  special-purpose  com¬ 
ponents  in  the  data  processing  subsystems,  e.g.,  special-purpose 
memory  components,  such  as  boot  memory  or  memory  whose  size  is 
tied  to  fixed  hardware  characteristics,  or  for  other  reasons  that  are 
properly  justified. 

3.2.8.1.2  Computer  Resource  Reserves  for  Operational 
Ground  Equipment.  For  the  purposes  of  this  specification,  the 
operational  data  processing  subsystems  of  the  ground  elements  of  the 
space  system  are  defined  to  comprise  all  computer  hardware,  soft¬ 
ware,  and  firmware  required  to  support  operational  missions  that  are 
not  in  space  elements.  Note,  however,  that  the  worst  case  loading, 
capacity,  throughput,  and  access  rate  requirements  referred  to  in  this 
specification  shall  consider  and  include  the  requirements  placed  upon 
the  ground  equipment  data  processing  subsystems  by  the  operational 
requirements  and  by  all  other  space  system  functions. 

To  suppoU  program  expansion  in  terms  of  additional  use  of  existing 
functions,  the  following  reserve  requirements  shall  be  provided  in  the 
ground  elements  of  the  operational  data  processing  subsystems  of  the 
space  system; 

a.  The  data  processing  subsystems  of  the  ground  elements  shall 
be  capable  of  data  throughput  that  is  100  pv  '-  eni  greater 
than  that  required  to  satisfy  the  v'orst  case  data  processing 
requirements  that  could  jointly  load  the  operational  ground 
equipment  data  processing  subsystems  of  the  ground 
elements. 

b.  Under  the  additional  data  throughput  specified  (i.e.,  100 
percent  greater  than  that  required  to  satisfy  the  worst  case 
data  processing  requirements  that  could  jointly  load  the  data 
processing  subsystems  of  the  ground  elements),  the  data 
processing  subsystems  of  the  ground  elements  shall  meet  the 
originally  stated  functional  and  performance  computational 
requirements,  including  timing  requirements. 

In  addition,  the  components  of  the  data  processing  subsy.sterur  of 
the  ground  elements  shall  satisfy  the  computer  resource  reserve 
requirements  stated  in  the  following  subparagraphs.  For  the  purpose 
of  the  following  subparagraphs,  the  term  processor  is  used  to  mean 
any  single  computer  in  the  ground  elements,  of  any  size,  whether  of 
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general-purpose  or  special-purpose  usage,  including  both  single  pro¬ 
cessor  architecture  and  multiprocessor  architecture  computers  (e.g.,  a 
workstation,  personal  computer,  microprocessor,  minicomputer,  main¬ 
frame,  vector  processor,  and  so  forth). 

3.2.8.1.2.1  Data  Processing  Subsystems  Processor 
Reserves.  Within  the  processing  environment  of  the  data  processing 
subsystems  of  the  ground  elements,  each  processor  shall: 

a.  Have  an  instruction  execution  rate  sufHcient  to  process  a 
workload  that  is  100  percent  greater  than  the  worst  case 
processor  utilization  workload  that  could  load  that  processor. 

b.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  an  instruc¬ 
tion  execution  rate  sufficient  to  process  a  workload  that  is 
200  percent  greater  than  the  worst  case  processor  utilization 
workload  that  could  load  that  processor. 

Under  the  additional  workloads  specified,  the  processor,  or  the 
augmented  processor,  shall  meet  the  originally  stated  functional  and 
performance  computational  requirements,  including  timing  require¬ 
ments,  allocated  to  that  processor. 

3.2.8.1.2.2  Data  Processing  Subsystems  Primary  Memory 
Reserves.  Within  the  environment  of  the  data  processing  subsystems 
of  the  ground  elements,  the  primary  memory  for  each  processor  shall: 

a.  Have  100  percent  greater  memory  capacity  than  the  worst 
case  memory  size  requirement  for  that  primary  memory 
component,  if  operating  under  a  nonvirtual  operating  system. 
If  operating  under  a  virtual  operating  system,  the  virtual 
memory  capacity  for  that  processor  shall  provide  for  100 
percent  greater  virtual  memory  capacity  than  the  worst  case 
virtual  memory  size  requirement  for  that  processor. 

b.  Have,  or  be  capable  of  having  memory  added  (through  mod¬ 
ification,  addition,  or  replacement)  to  attain,  a  200  percent 
greater  memory  capacity  than  the  worst  case  memory  size 
requirement  for  that  primary  memory  component,  if  opera¬ 
ting  under  a  nonvirtual  operating  system.  If  operating  under 
a  virtual  operating  system,  the  virtual  memory  capacity  for 
that  processor  shall  have,  or  be  capable  of  having  memory 
added  (through  modification,  addition,  or  replacement)  to 
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attain,  a  200  percent  greater  virtual  memory  capacity  than 
the  worst  case  virtual  memory  size  requirement  for  that 
processor. 

c.  Have  a  memory  access  rate  sufficient  to  process  a  workload 
that  is  100  percent  greater  than  the  worst  case  memory 
access  workload  for  that  primary  memory  component. 

d.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  a  memory 
access  rate  sufficient  to  process  a  workload  that  is  200 
percent  greater  than  the  worst  case  memory  access  workload 
for  that  primary  memory  component. 

Under  the  additional  workloads  specified,  any  processor  accessing  a 
primary  memory,  or  augmented  memory,  shall  meet  the  originally 
stated  functional  and  performance  computational  requirements, 
including  timing  requirements  allocated  to  that  processor.  Note  that  if 
any  processor  accessing  a  primary  memory  is  executing  under  a 
virtual  memory  operating  system,  the  worst  case  memory  access 
workloads  must  consider  memory  accesses  due  to  paging,  in  addition 
to  memory  accesses  due  to  performing  the  functional  requirements 
using  that  primary  memory. 

3.2.8.1.2.3  Data  Processing  Subsystems  Peripheral  Data 
Storage  (Secondary  Memory)  Reserves.  Within  the  environment 
of  the  data  processing  subsystems  of  the  ground  elements,  each 
peripheral  data  storage  (secondary  memory)  component  shall: 

a.  Have  100  percent  greater  storage  capacity  than  the  worst 
case  storage  requirement  for  that  peripheral  data  storage 
component. 

b.  Have,  or  be  capable  of  having  storage  added  (through  modi¬ 
fication,  addition,  or  replacement)  to  attain,  a  200  percent 
greater  storage  capacity  than  the  worst  case  storage  require¬ 
ment  for  that  peripheral  data  storage  component. 

c.  Have  an  access  rate  sufficient  to  process  a  workload  that  is 
100  percent  greater  than  the  worst  case  access  workload  for 
that  peripheral  data  storage  component. 

d.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  an  access 
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rate  sufficient  to  process  a  workload  that  is  200  percent 
greater  than  the  worst  case  access  workload  for  that 
peripheral  data  storage  component. 

Under  the  additional  workloads  specified,  any  processor  accessing  a 
peripheral  data  storage  component,  or  augmented  peripheral  data 
storage  component,  shall  meet  the  originally  stated  functional  and 
performance  computational  requirements,  including  timing  require¬ 
ments,  allocated  to  that  processor.  Note  that  if  any  processor  accessing 
a  peripheral  data  storage  component  is  executing  under  a  virtual 
memory  operating  system,  the  worst  case  memory  access  workloads 
must  consider  memory  accesses  due  to  paging,  in  addition  to  memory 
accesses  due  to  performing  the  functional  requirements  using  that 
peripheral  data  storage  component. 

3.2.8.1.2.4  Data  Processing  Subsystems  Data  Transmission 
Media.  Within  the  environment  of  the  data  processing  subsystems  of 
the  ground  elements,  each  data  transmission  medium  (e.g.,  local  or 
global  bus  or  channel)  shall: 

a.  Have  sufficient  capacity  to  support  data  throughput  that  is 
100  percent  greater  than  the  worst  case  data  throughput  that 
could  load  that  data  transmission  medium. 

b.  Have,  or  be  capable  of  being  augmented  (through  modifi¬ 
cation,  addition,  or  replacement)  to  have,  sufficient  capacity 
to  support  data  throughput  that  is  200  percent  greater  than 
the  worst  case  data  throughput  that  could  load  that  data 
transmission  medium. 

c.  Have  a  data  access  rate  sufficient  to  process  a  workload  that 
is  100  percent  greater  than  the  worst  case  data  access  work¬ 
load  for  that  data  transmission  medium. 

d.  Be  capable  of  attaining,  or  of  being  augmented  (through 
modification,  addition,  or  replacement)  to  attain,  a  data 
access  rate  sufficient  to  process  a  workload  that  is  200 
percent  greater  than  the  worst  case  data  access  workload  for 
that  data  transmission  medium. 

Under  the  additional  workloads  specified,  any  processor,  or  aug¬ 
mented  processor,  accessing  the  data  transmission  medium,  or  aug¬ 
mented  data  transmission  medium,  shall  meet  the  originally  stated 
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functional  and  performance  computational  requirements,  including 
timing  requirements,  allocated  to  that  processor. 

3.2.8.1.2.5  22jaa _ Processing  Subsystems _ Software/Firm¬ 

ware.  The  software  and  firmware  in  each  data  processing  subsystem 
of  the  ground  elements  shall  be  designed  (e.g.,  via  parameterization, 
appropriate  sizing  of  data  structures,  or  other  methods)  so  that  utili¬ 
zation  of  the  computer  performance  reserves  speciHed  due  to  addi¬ 
tional  use  of  existing  functions  can  be  accomplished  without  changes  in 
the  software  or  firmware  logic.  Any  hardware  augmentations  neces¬ 
sary  to  meet  the  expansion  requirements  specified  shall,  where  prac¬ 
tical,  be  designed  so  that  the  software  and  firmware  in  each  data 
processing  subsystem  of  the  ground  elements  is  upward  compatible 
with  the  implementation  of  those  augmentations. 

3.2.8.2  Nononerational  Computer  Resource  Reserves 

3.2.8.2.1  Computer  Software  Maintenance  Resources: 
Additional  Growth  Capability.  The  computer  resources  used  for 
computer  software  maintenance  shall  be  capable  of  accommodating 
the  specified  growth  requirements  of  the  operational  computer 
resources  without  necessitating  any  major  modifications. 

3.2.8.2.2  Computer  Resources,  in  Trainers:  Additional 
Growth  Capability.  The  trainer  shall  be  capable  of  accommodating 
the  growth  requirements  of  the  operational  computational  equipment 
without  necessitating  major  modifications. 

3.2.8.2.3  (TBS) 

3.2.8.3  Other  Flexibility  and  Expansion  Requirements. 
System  flexibility  and  expansion  shall  be  enhanced  by  (TBS). 

3.2.9  Portability.  Not  applicable.  The  only  portability  require¬ 
ments  for  the  system  are  stated  in  Paragraph  3.3.11  and  subpara¬ 
graphs  for  computer  resources  and  in  Paragraph  3.3.7  and  subpara¬ 
graphs  for  transportation. 

3.3  DESIGN  AND  CONSTRUCTION 


3.3.1  Materials 
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3.3.1.1  Toxic  Products  and  Formulations.  (Not  applicable) 

3.3.1. 2  Materials.  Processes,  and  Parts  for  Space  Vehicle 
Equipment.  Unless  otherwise  speciHed  in  the  contract,  the  parts, 
materials,  and  processes  shall  be  selected  and  controlled  in  accordance 
with  documented  procedures  to  satisfy  the  specified  requirements. 

The  selection  and  control  procedures  shall  emphasize  quality  and 
reliability  to  meet  the  mission  requirements  and  to  minimize  total  life 
cycle  cost  for  the  applicable  system.  An  additional  objective  in  the 
selection  of  parts,  materials,  and  processes  shall  be  to  minimize  the 
variety  of  parts,  related  tools,  and  test  equipment  required  in  the 
fabrication,  installation,  and  maintenance  of  the  space  equipment. 
However,  identical  electrical  connectors,  identical  Httings,  or  other 
identical  parts  shall  not  be  used  on  space  equipment  where  inadver¬ 
tent  interchange  of  items  or  interconnections  could  cause  possible 
malfunction.  The  parts,  materials,  and  processes  selected  shall  be  of 
sufHcient  proven  quality  to  allow  the  space  equipment  to  meet  the 
functional  performance,  reliability,  and  strength  as  required  during  its 
life  cycle,  including  all  environmental  degradation  effects. 

3.3.1.2.1  Part  Selection.  Parts  for  space  equipment  shall  be  in 
accordance  with  MIL-STD-1547.  Care  shall  be  exercised  in  the 
selection  of  materials  and  processes  for  the  space  equipment  to  avoid 
stress  corrosion  cracking  in  highly  stressed  parts  and  to  preclude 
failures  induced  by  hydrogen  embrittlement.  Parts,  materials,  and 
processes  shall  be  selected  to  ensure  that  any  damage  or  deterioration 
from  the  space  environment  or  the  outgassing  effects  in  the  space 
environment  will  not  reduce  the  performance  of  the  space  equipment 
beyond  the  specified  limits. 

3.3. 1.2.2  Material  Selection.  Materials  shall  be  selected  that 
have  demonstrated  their  suitability  for  the  intended  application. 

Where  practicable,  fungus-inert  materials  shall  be  used.  Combustible 
materials  or  materials  Aat  can  generate  toxic  outgassing  or  toxic 
products  of  combustion  shall  not  be  used  if  cost-effective  alternatives 
exist.  Materials  shall  be  corrosion  resistant  or  shall  be  suitably  treated 
to  resist  corrosion  when  subjected  to  the  speciOed  environ-ments. 
Protection  of  dissimilar  metal  combinations  shall  be  in  accord-ance 
with  MIL-STD-889. 

Structural  properties  of  materials  for  use  in  space  applications  shall 
be  taken  from  MIL-HDBK-5  for  metals  and  from  MIL-HDBK-17  for 
plastics.  Properties  not  listed  shall  be  based  upon  appropriate 
material  tests.  When  such  data  are  not  available,  they  shall  be 
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determined  by  approved  test  methods.  A  sufficient  number  of  tests  to 
establish  values  for  mechanical  properties  on  a  statistical  basis  shall  be 
performed. 


Materials  for  the  space  equipment  shall  be  selected  for  low 
outgassing  in  accordance  with  SP-R-0022  (NASA  JSC).  The  total  mass 
loss  shall  be  less  than  1  percent,  and  the  collected  volatile  condens¬ 
able  material  shall  be  less  than  0.1  percent  when  heated  in  vacuum  to 
125  degrees  C  and  collected  at  23  degrees  C.  The  hygroscopic  nature 
of  many  materials  such  as  composites,  electroformed  nickel,  and 
anodic  coatings  for  aluminum  should  be  recognized,  if  they  are  used, 
since  they  emit  water  in  a  vacuum  and  therefore  may  be  unsuitable 
for  some  applications. 


3.3.1. 3  Materials.  Processes,  and  Parts  for  Ground 
Equipment.  The  selection  and  control  procedures  for  parts,  materials, 
and  processes  shall  emphasize  quality  and  reliability  to  meet  the 
mission  requirements  and  to  minimize  total  life  cycle  cost  for  the 
applicable  system.  An  additional  objective  in  the  selection  of  parts, 
materials,  and  processes  shall  be  to  minimize  the  variety  of  parts, 
related  tools,  and  test  equipment  required  in  the  fabrication, 
installation,  and  maintenance  of  the  equipment. 


3.3.1. 3.1  Part  Selection.  MIL-STD-1547  shall  be  used  as  a 
guide  in  the  application  and  selection  of  parts.  In  addition,  the 
following  part  types  shall  be  considered  as  acceptable  for  ground 
equipment: 


a.  Semiconductor  Devices.  All  Class  B  or  Class  S  semi-conductor 
devices  selected  from  the  MIL-S- 19500  Qualified  Parts  List 
(QPL).  No  germanium  device  shall  be  utilized  where  a  silicon 
counterpart  exists. 


b.  Microelectronics.  All  Class  B  or  Class  S  microelectronic 

devices  selected  from  the  MIL-M-38510  QPL.  No  germanium 
device  shall  be  utilized  where  a  silicon  counterpart  exists. 


c. 


Passive  Piece  Parts.  All  piece  parts,  including  capacitors, 
resistors,  connectors,  and  relays,  selected  as  Established 
Reliability  types  with  at  least  a  P  or  MIL-SPEC  failure  rate 
level,  whichever  is  more  reliable. 
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d.  Electrical  Connectors.  Electrical  connectors  selected  in 
accordance  with  MIL-C-38999  and  MIL-C-83723  (covering 
circular  connectors),  MIL-C-55302  (covering  printed  circuit 
board  connectors),  MIL-C-28748  (covering  rectangular  rack 
and  panel  connectors),  and  other  connector  types  selected  in 
accordance  with  Requirement  10  of  MIL-STD-454.  Electrical 
connectors  requiring  potting  compound  material  shall  not  be 
used. 

3.3.1.3.2  Material  Selection.  Materials  shall  be  selected  that 
have  demonstrated  their  suitability  for  the  intended  application. 

Where  practicable,  fungus-inert  materials  shall  be  used.  Combustible 
materials  or  materials  that  can  generate  toxic  outgassing  or  toxic  pro¬ 
ducts  of  combustion  shall  not  be  used  if  cost-effective  alternatives 
exist.  Materials  shall  be  corrosion  resistant  or  shall  be  suitably  treated 
to  resist  corrosion  when  subjected  to  the  specified  environ-ments. 

3.3.1.3.3  Resistance  to  Degradation  and  Wearout 

a.  Where  dissimilar  metals  are  used  and  come  into  contact, 
MIL-STD-889  and  MIL-STD-454,  Requirement  16,  shall  be 
followed  to  minimize  corrosion  effects. 

b.  Metals  used  in  construction  shall  be  resistant  to  corrosion. 
MIL-STD-1568  may  be  used  as  a  guideline.  Ferrous  alloys 
shall  be  in  accordance  with  MIL-STD-454,  Requirement  15. 

c.  Fabric  (textile)  or  plastic  pressure-sensitive  (adhesive  or 
friction)  tape  shall  not  be  used  for  electrical  insulation 
purposes.  Fastener  hardware  selection  and  use  shall  be  in 
accordance  with  MIL-STD-454,  Requirement  12. 

d.  Materials  used  for  encapsulation  and  embedment  shall  be 
selected  for  their  intended  operational  environmental 
conditions.  Only  those  materials  which  meet  or  exceed  the 
requirements  of  MIL-S-8516,  MIL-S-23586,  or  MIL-I-81550 
shall  be  used. 

e.  All  exterior  equipment  including  shelters  of  all  kinds  shall  be 
assembled  with  MIL-S-81733  sealant  between  all  faying 
surfaces.  All  fasteners  (screws,  bolts,  rivets,  etc.)  protruding 
through  the  outside  surfaces  or  exposed  in  any  way  must  be 
wet-dipped  in  MIL-S-81733  sealant  before  being  inserted 
and  fastened.  All  exterior  connector  bases,  access  panels,  and 
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so  forth,  must  also  have  MIL-S-81733  sealant  applied  wet  to 
the  faying  surface  immediately  prior  to  being  attached  to  the 
exterior  surface. 

f.  Spot  welding  to  fasten  exterior  equipment  panel  skins  or 
exterior  shells  and  covers  to  structural  members  is  not 
allowed. 

g.  Fungus  resistance  must  be  designed  in  by  using  fungus- 
resistant  materials  in  accordance  with  MIL-STD-454, 
Requirement  4. 

h.  Vinyl  or  polyvinylchloride  materials  shall  not  be  used  due  to 
their  well-known  fungus  nutrient  characteristics  and  the 
dangers  of  outgassing  corrosive  products  during  storage. 

i.  Felt,  leather,  cork,  asbestos,  or  glycol-impregnated  gaskets 
shall  not  be  used. 

j.  The  design  shall  use  arc-resistant  materials  in  those  locations 
where  materials  may  be  degraded  by  exposure  to  arcs, 
corona  discharge,  or  related  electrical  discharges. 

k.  Contacts  on  circuit  cards  or  other  removable  modules  shall  be 
designed  to  be  abrasion  and  wear  resistant,  to  be  resistant  to 
repeated  reseatii.g,  removal,  and  reinsertion  actions.  Sliding 
surfaces  of  removable  modules  shall  be  suitably  treated  to 
prevent  galling. 

l.  Solid  film  lubricants  may  be  used  except  where  exposure  to 
fuels,  hydraulic  fluids,  solvents,  and  so  forth,  occurs. 

m.  The  equipment  shall  be  designed  to  include  adequate  drain 
holes  and  corrosion  protection  in  those  locations  where 
moisture,  condensation,  or  rain  can  enter  or  accumulate. 

3.3.1.3.4  Structural  Properties.  Structural  properties  of 
materials  shall  be  taken  from  MIL-HDBK-5  for  metals  and  from  MIL- 
HDBK-17  for  plastics.  Properties  not  listed  shall  be  based  upon 
appropriate  material  tests.  When  such  data  arc  not  available,  they 
shall  be  determined  by  approved  test  methods.  A  sufficient  number 
of  tests  to  establish  values  for  mechanical  properties  on  a  statistical 
basis  shall  be  performed. 
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33.2  Electromagnetic  Radiation.  Electrical  and  electronic 
equipment  shall  operate  independently  and  in  conjunction  with  other 
equipment  that  may  be  placed  nearby.  The  operation  of  such  equip¬ 
ment  shall  not  be  adversely  affected  by  interference  voltages  and 
fields  reaching  it  from  external  sources.  In  addition,  the  equipment 
shall  not  be  a  source  of  interference  which  might  adversely  affect  the 
operation  of  other  equipment.  The  system  shall  be  designed  for 
electromagnetic  compatibility  in  accordance  with  MIL-STD-1S41.  The 
system  ground  facilities  shall  be  designed  for  electromagnetic 
compatibility  in  accordance  with  MIL-STD-1542, 

3.3.2.1  Electromagnetic  Radiation  for  Space  Vehicle 
Equipment.  The  space  equipment  shall  be  designed  for  electro¬ 
magnetic  compatibility  in  accordance  with  MIL-STD-1541.  For 
Shuttle-launched  equipment,  the  requirements  of  JSC  07700,  Volume 
XIV  also  apply. 


Emissions  of  space  equipment  shall  be  controlled  in  accordance 
with  MIL-STD-1541  requirements  and,  for  Shuttle-launched  equip¬ 
ment,  in  accordance  with  the  requirements  of  JSC  07700,  Volume  XIV. 


3.3.2.2  Electromagnetic  Radiation  for  Ground  Equipment 
Although  ground  equipment  need  not  meet  the  flight  electromagnetic 
compatibility  requirements,  it  is  necessary  that  it  not  be  a  source  of 
interference  to,  or  be  affected  by,  flight  hardware.  Ground  equipment 
which  is  to  be  used  at  the  launch  site,  particularly  that  for  Shuttle- 
launched  space  equipment,  also  shall  meet  the  emission  requirements 
imposed  by  the  launch  site. 


3.3.2.2.1  Red/Black  Interface  Control.  Equipment  layout  and 
electrical  interfaces  shall  be  designed  in  accordance  with  NACSIM- 
5203. 


3.3.2.2.2  TEMPEST  Requirements.  The  system  equipment 
shall  meet  TEMPEST  requirements  specified  in  NACSIM-5100A. 
TEMPEST-approved  equipment  shall  be  used  as  required;  however,  to 
allow  for  the  use  of  items  for  which  TEMPEST-approved  equipment  is 
not  available,  physical  security  shall  be  implemented.  Additionally, 
other  physical  measures  such  as  RFI  cabinets  and  screen  rooms  shall 
be  used  if  required.  Individual  equipment  need  not  meet  TEMPEST 
requirements  at  the  unit  level,  if  the  design  or  installation  of  the 
system  equipment  in  the  facilities  enables  TEMPEST  requirements  to 
be  met  at  the  primary  control  zone  of  the  facility.  The  specified  levels 
of  radiation  shall  not  be  exceeded  at  the  secure  site  perimeter. 
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333  Nameplates  and  Product  Marking.  The  system  CIs  and 
each  interchangeable  subassembly  shall  be  identified  by  a  nameplate. 
The  nameplate  identification  may  be  attached  to,  etched  in,  or  marked 
directly  on  the  item.  The  nameplate  shall  utilize  suitable  letter  size 
and  contrasting  colors,  contrasting  surface  finishes,  or  other  techniques 
to  provide  identiHcation  that  is  readily  legible.  The  nameplate  shall  be 
capable  of  withstanding  cleaning  procedures  and  environmental 
exposures  anticipated  during  the  service  life  of  the  item  without 
becoming  illegible.  Metal  foil  nameplates  may  be  applied  if  they  can 
be  placed  in  an  area  where  they  cannot  interfere  with  proper  opera¬ 
tion  should  they  inadvertently  become  detached.  Metal  stamping  shall 
not  be  used.  Where  practicable,  identification  nameplates  on  com¬ 
ponents  and  subassemblies  shall  be  in  locations  which  permit  obser¬ 
vation  of  the  marking  at  the  next  higher  level  of  assembly.  Name¬ 
plates  shall  contain,  as  a  minimum,  the  following: 

a.  Item  or  Cl  number 

b.  Serial  number 

c.  Lot  number 

d.  Manufacturer 

e.  Contract  number 

f.  Nomenclature 

3.3.3.1  Data  Cards.  When  size  limitations,  cost,  or  other  con¬ 
siderations  preclude  marking  all  applicable  information  on  an  item,  the 
nameplate  may  provide  a  reference  key  to  cards  or  documents  in 
which  the  omitted  nameplate  information  may  be  found.  A  copy  of 
the  referenced  nameplate  information  or  card  shall  accompany  the 
item  or  assembly  containing  the  item  during  ground  tests  and  ground 
operations. 

3.3.3.2  Nameplates  and  Product  Marking  for  Space 
Vehicle  Equipment.  The  marking  of  any  two  or  more  items 
intended  for  space  applications  with  the  same  item  number  or 
identiHcation  shall  indicate  that  they  may  be  capable  of  being  changed, 
one  for  another,  without  alteration  of  the  items  themselves  or  of 
adjoining  equipment  if  the  items  also  meet  all  other  specified 
requirements  (such  as  acceptable  lot  date  code). 
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3333  *'NOT  FOR  FLIGHT"  Marking.  Space  equipment  which 
by  intent  or  by  material  disposition  are  not  suitable  for  use  in  flight, 
and  which  could  be  substituted  accidentally  for  flight  or  flight  spare 
hardware,  shall  be  red-tagged  or  striped  with  red  paint,  or  both,  to 
prevent  such  substitution.  The  red  tag  shall  be  conspicuous  and 
marked  "NOT  FOR  FLIGHT."  The  red  paint  shall  be  material  compatible 
and  the  stripes  unmistakable. 

333.4  Nameplates  and  Product  Marking  for  Ground 
Equipment.  The  marking  of  any  two  or  more  items  intended  for 
ground  applications  with  the  same  item  number  or  identification  shall 
indicate  that  they  possess  such  functional  and  physical  characteristics 
as  to  be  equivalent  in  performance  and  durability  and  therefore  can 
be  changed,  one  for  another,  without  alteration  of  the  items  them¬ 
selves  or  of  adjoining  items. 

Ground  equipment,  assemblies,  and  parts  shall  be  marked  for 
identification  in  accordance  with  MIL-STD-454,  Requirement  67. 
Nomenclature  and  reference  designations  for  ground  equipment  shall 
meet  the  requirements  of  MIL-E-4158. 

3.3.3.5  Software  Media  Marking.  Software  media  marking 
requirements  are  stated  in  the  computer  resources  Paragraph  3.3.11 
and  subparagraphs. 

3.3.4  Workmanship.  Equipment  shall  be  manufactured,  pro¬ 
cessed,  tested,  and  handled  such  that  the  finished  items  are  of 
sufficient  quality  to  ensure  reliable  operation,  safety,  and  service  life. 
The  items  shall  be  free  of  defects  that  would  interfere  with  opera¬ 
tional  use  such  as  excessive  scratches,  nicks,  burrs,  loose  materials, 
contamination,  and  corrosion.  Workmanship  for  ground  equipment 
shall  be  in  accordance  with  the  requirements  of  MIL-STD-454, 
Requirement  9. 

3.3.5  Interchangeability 

3.3.5. 1  Space  Vehicle  Equipment  Interchangeability.  The 
design  of  the  space  elements  shall  make  provisions  for  the  factory 
replacement  of  components  and  subassemblies  and  for  the  prelaunch 
installation  or  replacement  of  explosive  ordnance  devices,  batteries, 
and  major  space  vehicle  components. 

3.3.5.2  Ground  Equipment  Interchangeability.  To  the  extent 
practicable,  the  design  of  the  ground  equipment  shall  make  provisions 
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for  modular  replacement  of  components  to  expedite  maintenance  and 
repair.  The  interchangeability  requirements  of  MIL-STD-454,  Re¬ 
quirement  7  shall  apply  for  all  ground  equipment.  To  the  maximum 
extent  possible,  equipment  shall  be  designed  as  modular  plug-in 
devices  and  shall  be  readily  replaceable  or  interchangeable  with 
identical  devices.  The  plug-in  devices  shall  be  marked  and  keyed  to 
preclude  insertion  or  installation  in  the  wrong  position  or  location.  All 
components  performing  identical  functions  shall  be  physically  and 
electrically  interchangeable  without  requiring  any  preparation  other 
than  minor  adjustments,  such  as  resetting  of  external  switches,  con¬ 
nection  of  cables,  or  insenion  of  plug-in  modules.  Attention  shall  be 
directed  toward  standardizing  form,  fit,  and  function  of  like  equipment 
modules  to  ensure  interchangeability.  This  includes  the  use  of  stand¬ 
ard  interequipment  communications,  man-machine  interface,  soft¬ 
ware,  and  data  processing. 

3.3.6  Safety.  The  system  design  shall  be  such  that  hazards  to 
personnel,  to  the  system,  and  to  the  associated  equipment  are  either 
eliminated  or  controlled  throughout  all  phases  of  the  system  life  cycle. 
The  safety  requirements  shall  be  in  accordance  with  MIL-STD-1574. 

A  safety  hazard  to  personnel  and  surrounding  equipment  shall  not  be 
created  during  installation,  maintenance,  ground  test,  transportation, 
and  operational  use.  Safety  procedures  shall  be  documented  and 
implemented  to  assure  maximum  freedom  from  accidents  attributable 
to  facilities,  equipment,  and  personnel.  The  safety  requirements  shall 
be  formulated  to  achieve  an  integrated  system  safety  engineering 
effort.  Procedures  shall  be  used  and  precautions  taken  to  preclude  the 
dropping  of  tools  or  other  items  that  might  injure  personnel  or  damage 
sensitive  equipment  during  installation,  maintenance,  ground  test,  and 
transportation.  The  safety  requirements  and  procedures  shall  comply 
with  applicable  Range  Safety  manuals. 

3.3.6. 1  Space  Transportation  System  Pavload  Safety.  For 
all  payloads  which  are  to  be  launched  by  the  STS,  the  safety  require¬ 
ments  also  shall  be  in  accordance  with  Chapter  2  of  NHB  1700.7 
(NASA).  For  these  payloads,  it  is  required  that  the  payload  must 
tolerate  a  minimum  number  of  failures  and/or  operator  errors  deter¬ 
mined  by  the  consequence  of  any  hazardous  functions.  For  catas¬ 
trophic  hazards  or  hazards  that  would  result  in  personnel  injury  or 
loss  of  the  Orbiter  or  STS  facilities  and  equipment,  the  hazard  shall  be 
controlled  such  that  no  combination  of  two  failures,  operator  errors,  or 
radio-frequency  signals  would  unleash  the  hazard.  For  critical  hazards 
or  hazards  that  would  result  in  damage  to  STS  equipment  or  in  the  use 
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of  contingency  or  emergency  procedures,  the  hazard  shall  be  con¬ 
trolled  such  that  no  single  failure,  or  operator  error,  will  unleash  the 
hazard.  Hazardous  functions  are  thereby  controlled  with  either  two  or 
three  inhibits,  depending  on  whether  the  hazard  is  critical  or 
catastrophic. 

In  addition.  Chapter  2  of  NHB  1700.7  (NASA)  defines  safety 
requirements  for  space  equipment  structural  design,  stress  corrosion, 
pressure  vessels,  sealed  containers,  hazardous  materials,  pyrotech¬ 
nics,  destruct  subsystems,  radiation,  electrical  subsystems,  flammable 
atmospheres,  and  reflown  hardware. 

3.3.6.2  Ground  Equipment  Safety.  The  safety  requirements 
for  ground  equipment  shall  be  in  accordance  with  SAMTO  HB  S-100 
(designated  by  NASA  as  KHB  1700.7)  and  with  MIL-STD-454, 
Requirement  1. 

3.3.6.2.1  Electrical.  The  system  design  shall  incorporate 
methods  to  protect  personnel  from  accidental  contact  with  voltages  in 
excess  of  30  volts.  Appropriate  voltage  interlocks  shall  be  provided. 

3.3.6.2.2  Acoustic  Noi.se.  System  equipment  shall  not  generate 
acoustic  noise  in  excess  of  70  decibels  adjusted  (dBa)  continuous  or 
140  dB  of  impulsive  noise.  System  acoustic  noise  levels  shall  not 
exceed  the  noise  level  prescribed  in  MIL-STD-1472. 

3.3.6.2.3  Personnel  Safety.  Platforms,  ladders,  access,  and  task 
lighting  shall  be  provided  for  all  items  requiring  inspection, 
maintenance,  service,  or  replacement. 

3.3.7  Human  Engineering.  Throughout  the  design  and  develop¬ 
ment  of  the  syst»;m,  the  applicable  criteria  in  MIL-STD-1472  shall  be 
judiciously  applied  to  obtain  effective,  compatible,  and  safe  man- 
equipment  interactions.  Provisions  such  as  tabs,  shoulders,  and 
different  thread  sizes  shall  be  employed  to  prevent  incorrect  assembly 
which  may  impair  the  intended  functions.  Human  engineering  goals 
shall  be  for  effective  use  of  human  resources.  The  goal  shall  be  to 
minimize  manning,  operator  error,  task  complexity,  and  task  time. 
Throughout  the  human  engineering  efforts,  particular  attention  shall 
be  given  to  equipment  and  computer  programs  supporting  time- 
critical  functions  which  require  personnel  interaction.  Displays  shall 
be  housed  in  consoles  or  equipment  racks.  The  console  design  shall 
consider  the  human  engineering  aspects  of  physical  dimensions, 
operating  controls,  and  viewing  areas.  Visual  considerations  shall 
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include  visual  display  legibility;  size,  shape,  and  spacing  of  indicators 
on  the  display  surface;  brightness,  color,  contrast,  and  blink  rate  for 
unique  annunciation  of  events;  and  ambient  lighting  and  its  effect  on 
the  display  surface  and  display  legibility  together  with  size  and  color¬ 
ing  of  lettering  and  other  markings  on  the  display  surfaces.  Aural 
considerations  shall  include  location  of  audible  alarms,  tone,  pitch, 
quality,  and  intensity. 

33.S  Nuclear  Control  Requirements.  Provisions  shall  be 
made  in  the  design  for  the  control  of  all  nuclear  material  so  as  to 
prevent  the  inadvertent  exposure,  loss,  or  detonation  of  nuclear 
material.  (TBS) 

33.9  System  Security.  Ground  facilities  shall  have  an  identified 
primary  security  control  zone  for  each  building  within  a  secure  site 
perimeter.  (TBS) 

3.3.10  Government-Furnished  Property _ llsa££ 

3.3.10.1  Government-Furnished  Equipment  for _ InCttrporaz 

tion.  The  following  GFE  shall  be  incorporated  into  the  system  as 
indicated: 

a.  COMSEC  equipment  (TBS) 

b.  Rocket  motors  (TBS) 

c.  Explosive  ordnance  (TBS) 

d.  Payload  equipment  (TBS) 

e.  Other  (TBS) 

3.3.10.2  Government-Furnished  Software  for  Incor¬ 
poration.  The  following  government-furnished  software  shall  be 
incorporated  into  the  system  as  indicated:  (none) 

3.3.10.3  Government-Furnished  Information  for _ In  cor: 

poration.  (none) 


3.3.11  Computer  Resources.  Computer  resources  include  all 
computer  software  and  the  associated  computational  equipment 
included  within  the  system.  Computational  equipment  is  that 
equipment,  including  the  associated  peripheral  devices,  which  is 
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capable  of  executing  machine-readable,  symbolically  expressed 
instructions.  These  computer  resources  shall  be  designed  and 
developed  in  accordance  with  an  integrated  plan  that  minimizes  the 
system  life  cycle  cost.  The  design  shall  provide  ample  memory  and 
processing  margins  to  accommodate  contingencies  and  growth  (see 
Paragraph  3.2.8).  A  distinction  is  made  between  the  computer 
resources  required  to  functionally  support  operations  and  computer 
resources  used  for  nonoperational  support.  For  operational  computer 
resources,  a  further  distinction  is  made  for  some  features  between  the 
requirements  for  computer  resources  in  space  elements  and  the 
requirements  for  computer  resources  in  ground  elements  of  the  space 
system.  Nonoperational  computer  resources  are  those  used  for  com¬ 
puter  software  maintenance,  those  embedded  in  test  equipment,  and 
those  included  in  other  functional  areas  such  as  in  trainers.  Require¬ 
ments  for  nonoperational  computer  resources  are  separated  by 
functional  area. 

3.3.11.1  Operational  Computer  Resources.  The  operational 
computer  resources  are  those  required  to  function  on-line  or  off-line 
during  one  or  more  phases  or  modes  of  the  operational  service  life. 

The  operational  computer  resources  shall  be  capable  of  performing  the 
required  real-time  computational  functions  in  the  space  system, 
including  the  space  vehicle,  the  launch  vehicle  (STS),  and  the  ground 
equipment.  These  real-time  functions  include  data  processing,  com¬ 
munications,  display,  and  control  functions.  In  addition,  the  opera¬ 
tional  computer  resources  shall  perform  the  required  nonreal-time 
data  processing  and  support  functions. 

3.3.11.1.1  Operational  Computational _ Equipment.  The 

computational  equipment  includes  processing  units;  special-purpose 
computational  devices;  main  storage;  peripheral  data  storage;  input 
and  output  units  such  as  printers,  graphic  displays,  video  display 
devices;  and  other  associated  devices.  To  the  extent  practicable,  the 
ground  operational  computational  capability  shall  be  provided  by 
commercially  available,  general-purpose  computer  equipment. 

3.3.11.1.1.1  Computer  Instruction  Performance  Rate. 

Within  its  operating  environment,  each  processing  unit  shall  perform 
instructions  at  a  rate  to  support  the  requirements  specified  herein.  An 
increased  capability  in  peak  real-time  functional  capability  beyond  the 
specific  requirements  identified  shall  be  provided  for  future  growth  as 
stated  in  Paragraph  3.2.8. 
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3.3.11.1.1.2  Data  Channel  Capacity.  The  maximum  input 
data-rate  capability  and  the  maximum  output  data-rate  capability  of 
each  channel,  when  operating  with  the  operational  application  com¬ 
puter  software,  shall  support  the  requirements  speci^ed  herein.  An 
increased  capability  in  channel  buffer  capacity  and  peak  data  rate 
beyond  the  specific  requirements  identified  shall  be  provided  for 
future  growth  as  stated  in  Paragraph  3.2.8. 

3.3.11.1.1.3  Main  Storage  (Primary  Memory).  The  capacity 
of  the  main  storage  (primary  memory)  in  operational  computers  shall 
support  the  requirements  specified  herein.  An  increased  capability  in 
storage  capability  beyond  the  specific  requirements  identified  shall  be 
provided  for  future  growth  as  stated  in  Paragraph  3.2.8.  The  main 
storage  in  operational  ground  computers  shall  be  modular  in  design. 

3.3.11.1.1.4  Peripheral  Data  Storage  (Secondary  Memorvl 
in  Ground  Installations.  The  capacity  of  the  peripheral  data  stor¬ 
age  (secondary  memory)  in  operational  computers  shall  support  the 
requirements  specified  herein.  An  increased  capability  in  storage 
capability  beyond  the  specific  requirements  identified  shall  be  pro¬ 
vided  for  future  growth  as  stated  in  Paragraph  3.2.8.  The  peripheral 
data  storage  in  operational  ground  computers  shall  be  modular  in 
design. 


3.3.11.1.1.5  Automatic  Initialization  and  Startup.  Each 
computer  shall  have  facilities  to  establish  automatic  initialization  and 
stanup  in  response  to  a  single  control  action.  These  facilities  shall 
provide  for  the  automatic  loading,  initialization,  and  starting  of  both 
the  operating  system  and  the  application  computer  software. 

3.3.11.1.2  Operating  Systems  Used  in  Operational 
Computers.  The  operating  system  for  each  operational  computer 
should  be  in  broad  use  and  should  have  a  demonstrable  record  of 
reliable  performance.  Where  applicable,  the  operating  systems  shall 
provide  the  scheduling,  task  switching  (on  a  priority  basis),  input/ 
output  control,  data  management,  and  memory  management 
capabilities  required  to  support  the  real-time  computational  and 
control  functions  of  the  computational  components.  The  operating 
system  shall  suppon  memory  protection.  The  operating  system  shall 
be  capable  of  exploiting  the  growth  requirements  specified  for  the 
operational  computational  equipment  without  necessitating  any 
modifications  (see  Paragraph  3.2.8). 
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Utility  libraries  which  are  available  to  all  tasks  at  link  time  through 
the  operating  system  link  and  load  facility  are  considered  part  of  the 
operating  system  itself. 

3.3.11.1.3  Operational _ Application _ Software 

3.3.11.1.3.1  Programming  Language.  Where  practicable, 
operational  application  computer  software  shall  be  written  in  Ada  per 
MIL-STD-1815  or  in  JOVIAL  J73  per  MIL-STD-1589.  Assembly 
language  shall  be  used  only  where  its  use  is  necessary  for  the  satis¬ 
faction  of  system  performance  requirements  or  where  its  use  is  cost 
effective  over  the  life  of  the  system.  The  term  "assembly  language" 
includes  the  use  of  microcode  and  microprogramming. 

3.3.11.1.3.2  Computer  Software  Tasks.  An  executable  entity 
of  a  computer  application  program  under  a  modern  operating  system 
is  defined  as  a  task.  (By  this  definition,  the  word  "task"  is  used  only  to 
mean  an  executable  entity  of  an  application  program  under  an 
operating  system,  and  it  does  not  mean  "something  that  has  to  be 
done",) 

3.3.11.1.3.3  Computer  Software  Structure.  The  structure  of 
application  programs  shall  be  organized  to  preserve  the  identification 
of  the  tasks  involved.  While  the  operating  system  supervises  software 
execution  by  task  and  task  priorities,  tasks  are  organized  for  program¬ 
ming  and  compiling  into  groups  of  tasks  (packages),  single  tasks,  and 
computer  software  units.  For  formal  configuration  identification  and 
control,  the  computer  application  software  and  structure  shall  be  iden¬ 
tified  as  Computer  Software  Configuration  Items  (CSCIs),  Computer 
Software  Components  (CSCs),  and  Computer  Software  Units. 

a.  Computer  Software  Configuration  Items.  The  top-level 
computer  software  end  item  is  a  CSCl.  A  CSCI  consists  of  one 
or  more  subtier  elements.  An  application  CSCI  consists  of  one 
or  more  tasks.  The  subtier  elements  of  a  CSCI  may  be  other 
CSCIs,  CSCs,  or  computer  software  units. 

b.  Computer  Software  Components.  A  CSC  is  a  subtler  element 
of  a  CSCI  which  may  be  defined  to  assist  in  the  development 
or  acquisition  process.  A  CSC  shall  consist  of  a  single  task  or 
may  be  subtler  to  a  task.  The  subtier  elements  of  a  CSC  may 
be  one  or  more  computer  software  units.  A  CSC  shall  not 
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consist  of  units  in  different  tasks.  If  the  identical  computer 
software  unit  is  used  in  various  tasks,  it  would  appear  in  the 
various  CSCs  completely  or  by  reference. 

c.  Computer  Software  Units.  A  computer  software  unit  may 
provide  information  or  may  provide  a  capability  to  perform 
one  or  more  operations,  or  both.  A  computer  software  unit 
may  contain  embedded  units.  Several  different  types  of 
computer  software  units  may  be  defined,  depending  upon 
the  computer  language  used. 

3.3.11.1.3.4  Structure  of  Modules.  Each  computer  software 
unit  shall  be  organized  into  two  subparts:  an  interface  and  an 
implementation. 

a.  The  interface  part  shall  characterize  the  capabilities  the 
computer  software  unit  makes  available  to  other  units  or  to 
other  interfacing  system  items  such  as  devices  or  human 
operators.  The  interface  part  shall  not  exceed  50  lines  of 
source  code  (excluding  comments). 

b.  The  implementation  part  of  each  computer  software  unit 
shall  define  how  the  operations  specified  in  the  interface  are 
to  be  provided.  The  implementation  part  shall  not  exceed 
100  lines  of  source  code  (excluding  comments). 

3.3.11.1.3.5  Hierarchical  Software  Design.  Operational 
computer  software  shall  be  designed  in  a  hierarchical  manner,  and  the 
levels  of  the  hierarchy  shall  correspond  to  the  levels  of  abstraction  of 
the  tasks  performed  by  the  program.  A  level  of  abstraction  is 
characterized  by: 

a.  The  types  of  data  objects  deHned  to  exist  on  that  level. 

b.  The  operations  deHned  to  be  performed  to  those  data 
objects. 

Each  level  of  the  program  shall  be  complete  in  itself.  Provisions  for 
incorporating  existing  computer  software  units  into  the  hierarchy  shall 
be  made  so  as  to  maximize  the  reuse  of  previously  developed  com¬ 
puter  software. 
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3.3.11.1.3.6  Standardized _ Control  Structures.  Only  closed 

control  structures  shall  be  used  in  the  construction  of  program  com¬ 
puter  software  units.  Closed  control  structures  are  structures  that 
have  a  single  entry  point  and  a  single  exit  point.  For  example,  closed 
control  structures  include: 

a.  A  simple  sequence. 

b.  A  conditional  selection. 

c.  An  iteration. 

3.3.11.1.3.7  Strong  Typing.  Explicit  declarations  shall  be 
provided  of  the  characteristics  attributed  to  computer  software 
elements.  No  computer  software  element  with  a  particular  collection 
of  declared  characteristics  shall  be  treated  as  if  it  had  some  other 
attributes.  A  method  shall  be  utilized  to  constrain  data  attributes  at 
compile  time. 


3.3.11.1.3.8  Encapsulation  of  Representations.  Every 
computer  software  element  which  is  used  to  represent  some  concept 
other  than  itself  shall  be  treated  as  encapsulated  within  the  declara¬ 
tion  of  the  concept  represented.  Encapsulated  means  that  external  to 
the  encapsulating  declaration,  no  operation  shall  be  applied  directly  to 
the  internal  elements.  For  example,  an  array  may  be  used  to  repre¬ 
sent  a  stack.  In  this  case,  the  array  is  the  representation  and  the  stack 
is  the  concept  represented.  Encapsulation  requires  that  no  array 
operations  may  be  applied  to  the  array  by  any  part  of  the  program 
other  than  that  part  that  implements  the  representation.  Other  parts 
of  the  program  may  apply  only  stack  operations. 

3.3.11.1.3.9  Software  Coding  Conventions.  All  computer 
software  shall  conform  to  the  following  coding  conventions; 

a.  The  structure  of  the  source  code  shall  reflect  the  design  of 
the  program. 

b.  Each  line  of  source  code  shall  contain  no  more  than  three 
statements,  i.e.,  no  more  than  three  semicolons  in  Ada  or 
JOVIAL.  Each  statement  in  a  line  with  multiple  statements 
shall  have  no  more  than  three  operations. 

c.  To  the  extent  practicable,  names  used  in  computer  software 
shall  be  consistent  with  those  used  in  the  system  design. 
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d.  Code  shall  be  written  such  that  no  code  is  modified  during 
execution. 

3.3.11.1.3.10  Software  Comments.  Comments  shall  be  incor¬ 
porated  throughout  each  computer  program  to  self-document  the 
organization  and  logic  of  the  program.  Computer  software  shall 
adhere  to  the  following  commenting  standards: 

a.  Banners.  A  banner  shall  be  the  first  item  in  each  computer 
software  listing.  The  banner  for  a  CSCI  listing  shall  state  the 
CSCI  title,  the  titles  of  all  subtier  CSCIs  if  any,  the  title  of  all 
tasks,  the  title  of  all  subtier  CSCs,  and  the  title  of  all  subtler 
com-puter  software  units  not  granted  the  level  of  a  CSC.  The 
banner  for  a  CSC  listing  shall  state  the  title  for  the  parent 
CSCI,  the  title  of  the  parent  task,  the  CSC  title,  and  the  title  of 
all  computer  software  units  in  the  CSC.  The  banner  for  each 
of  the  two  parts  of  a  computer  software  unit  listing  should 
state  the  title  for  the  parent  CSCI,  the  title  for  the  parent  CSC, 
the  title  for  the  parent  computer  software  unit  (if  any),  the 
title  of  the  computer  software  unit,  and  whether  the  part  is 
the  interface  or  the  implementation  part  of  the  computer 
software  unit. 

b.  Headers.  A  header  consisting  of  a  consecutive  block  of 
comments  shall  follow  the  banner  in  each  source  code  listing 
to  facilitate  the  understanding  and  readability  of  the  listing. 
The  header  shall  provide  a  prose  abstract  of  the  declarations 
and  processing  activities  to  assist  in  understanding  of  the 
program  code. 

c.  Special  Comments.  Special  comments  shall  be  included 
within  the  source  code  listing  to  assist  in  reading  particularly 
subtle  or  confusing  code.  Special  comments  may  supplement 
header  comments,  but  they  should  not  replace  the  header 
comments.  A  special  comment  shall  be  included  for  every 
logic  branch  and  join  point  to  characterize  the  intended 
operation  of  the  program  to  that  point. 

3.3.11.1.3.11  Message  Generation.  The  ground  operational 
computer  software  shall  generate  error  messages,  diagnostic  messages, 
and  alarm  messages  on-line  to  facilitate  real-time  fault  isolation  re¬ 
quired  to  maintain  the  system  in  operational  status  In  addition,  these 
ground  operational  computer  software  shall  generate  off-line  error 
and  diagnostic  messages  for  the  logging  of  fault  messages  onto  system 
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files  for  those  categories  of  faults  which  require  isolation  and  correc¬ 
tion  but  can  be  addressed  off-line  and  do  not  degrade  system  per¬ 
formance.  The  required  processing  time  to  identify  and  generate 
error  and  diagnostic  messages  shall  not  degrade  the  operational 
performance  of  the  system.  Messages  shall  conform  to  the  following: 

a.  With  the  exception  of  lengthy  diagnostic  procedures  for  use 
following  an  abnormal  condition,  processor  message  and 
advisory  formats  shall  not  require  additional  interpretation 
by  the  operator.  For  example,  table  lookups  and  references 
to  documentation  should  not  be  required. 

b.  Every  message  and  advisory  shall  inelude  a  unique  des¬ 
cription  of  the  condition  which  prompted  it. 

c.  On-line  error  messages  shall  contain  as  a  minimum  the 
following  information: 


(1) 

Time  error  was  detected 

(2) 

Textual  description  of  error  condition 

(3) 

Required  operator  action  where  applicable 

d.  Off-line  error  messages  shall  contain  as  a  minimum  the 
following  information: 

(I) 

Time  error  was  detected 

(2) 

Textual  description  of  error  condition 

(3) 

Required  operator  action  where  applicable 

(4) 

Identification  of  triggering  computer  software  unit 

(5) 

Identification  of  source  program  operation  being 
performed  at  the  time  of  the  error 

(6) 

Computer  software  or  system  execution  status 
following  the  error 

3.3.11.1.3.12 

Character  Set  Standards.  Character  sets  shall 

conform  to  standards  in  ANSI-STD  X  3.4-1968  (FIPS  PUB  1). 
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3.3.11.13.13  Growth.  The  operational  application  computer 
software  shall  satisfy  their  performance  requirements  without  the 
implementation  of  any  of  the  growth  provisions  identified  herein  for 
computational  equipment  (see  Paragraph  3.2.8).  However,  the 
application  programs  should  be  designed  to  be  capable  of  easily 
exploiting  any  of  the  identiHed  growth  provisions,  such  as  added 
memory,  which  may  be  implemented. 

3.3.11.1.4  Operational  Firmware.  Computer  programs  and 
data  stored  in  a  class  of  storage  that  cannot  be  modified  by  the  com¬ 
puter  during  processing  shall  be  considered  firmware.  Requirements 
on  operational  firmware  shall  be  the  same  as  those  on  operational 
application  computer  software. 

3.3.11.1.5  Computer  Resource  Utilization  Monitoring.  The 
ground  operational  computer  resources  shall  provide  a  capability 
which  can  be  exercised  under  operator  control  to  monitor,  record, 
display,  and  print  the  utilization  of  the  various  computer  resources. 
The  computer  resource  utilization  that  should  be  measurable  and 
recordable  during  real  time  operations  includes: 

a.  Job  timing,  that  is,  overall  CPU  utilization 

b.  Task  timing,  the  CPU  seconds  used  by  each  task 

c.  Computer  main  storage  (primary  memory)  utilization 

d.  Peripheral  data  storage  (secondary  memory)  utilization 

e.  A  trace  of  the  program  execution  sequence 

The  time  interval  between  recording  samples  shall  be  variable,  and 
the  types  of  data  collected  shall  be  options;  both  shall  be  under  opera¬ 
tor  control.  Deletion  of  the  options  shall  remove  the  execution  and 
storage  overhead  associated  with  the  options. 

3.3.11.2  Computer  Software  Maintenance  Resources 


3.3.11.2.1  Computational  Equipment  for  Computer  Soft¬ 
ware  Maintenance.  The  computational  equipment  for  computer 
software  maintenance  is  that  computational  equipment  required 
during  the  operational  service  life  to  develop  and  test  changes  to  the 
computer  software  used  in  operational  equipment  and  in  training 
equipment.  To  the  extent  practicable,  this  computational  equipment 
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for  computer  software  maintenance  shall  be  identical  to  the  compu¬ 
tational  equipment  used  for  computer  software  development.  In 
other  words,  the  computer  software  development  equipment  normally 
would  transition  to  the  computer  software  maintenance  facility.  The 
computer  software  maintenance  equipment  shall  be  capable  of  accom¬ 
modating  the  growth  requirements  of  the  operational  computational 
equipment  without  necessitating  any  hardware  modifications. 

3.3.11.2.2  Computer  Software  for  Computer  Software 
Maintenance  Computers.  The  operating  system  for  each  computer 
used  in  the  maintenance  of  operational  computer  software  shall  be 
capable  of  exploiting  the  growth  requirements  specified  for  the 
operational  computational  equipment  without  necessitating  any  major 
modifications.  Maintenance  of  operational  computer  software  shall  be 
supported  by  utility  programs  and  other  computer  software  running 
with  the  operating  system(s)  and  computer(s)  specifically  identified 
for  computer  software  maintenance.  The  operating  system(s)  and 
computer  software  used  for  computer  software  maintenance  shall 
provide  as  a  minimum  the  following  interactive  capabilities: 

a.  Editing 

b.  Compilation  which  produces  relocatable  object  code 

c.  If  applicable,  an  assembly  which  produces  relocatable  object 
code 

d.  Linker  and  loader 

e.  Generation,  maintenance,  and  initialization  of  storage  media 
for  programs  and  data 

f.  Diagnostics  to  support  fault  isolation 

g.  Debugging  tools 

h.  Program  library  facilities  for  both  source  and  object  code 

i.  Configuration  control  capability 

To  the  extent  practicable,  the  operating  system(s),  other  computer 
software,  and  firmware  to  be  used  for  computer  software  maintenance 
during  the  operational  service  life  shall  be  the  same  as  that  used  for 
computer  software  development. 
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3.3.11.2.3  Computer  Resource  Utilization  Monitoring.  The 
computer  resources  used  for  computer  software  maintenance  shall 
provide  a  capability  to  monitor,  record,  display,  and  print  the 
simulated  utilization  of  the  operational  computer  resources  under 
simulated  operational  conditions.  The  intent  of  this  capability  is  to 
provide  a  means  for  making  measurements  that  would  assure  that 
adequate  growth  margins  can  be  maintained  as  changes  are 
incorporated  during  the  operational  service  life. 

3.3.11.2.4  Tools  for  Computer  Software  Maintenance. 

Tools  required  for  the  initial  development  of  operational  computer 
software  and  firmware  shall  become  part  of  the  Computer  Software 
Maintenance  Resources.  These  tools  shall  be  capable  of  reuse  in 
testing  and  validating  changes  to  the  computer  software.  These  tools 
include  test  drivers,  simulated  data,  and  other  special-purpose 
devices.  For  example,  if  a  Microprocessor  Development  System  were 
used  to  develop  firmware,  the  Microprocessor  Development  System 
and  the  associated  computer  software  and  documentation  should  be 
controlled  and  retained  as  part  of  the  computer  software  maintenance 
resources  to  support  possible  change  activity  during  the  operational 
service  life  of  the  system. 

3.3.11.3  Computer  Resources  in  Test  Equipment.  Test 
equipment  is  that  equipment  required  to  support  the  maintenance, 
repair,  and  checkout  of  the  system  hardware  following  system 
deployment.  The  computer  resources  that  are  embedded  in  the  test 
equipment  shall  meet  the  requirements  specified  for  operational 
computer  resources  except  for  programming  language  requirements 
and  for  growth  potential.  Computer  software  for  use  in  automatic  test 
equipment  shall  be  written  in  ATLAS  per  ANSI/IEEE  416-1978,  where 
practicable. 

3.3.11.4  Computer  Resources  in  Trainers.  The  trainers  are 
the  equipment  to  be  used  for  the  training  of  system  operator  person¬ 
nel.  The  computer  resources  in  trainers  are  the  computer  software 
and  the  associated  computational  equipment,  controls,  and  displays 
embedded  in  the  trainers.  To  the  extent  practicable,  the  computa¬ 
tional  equipment  in  trainers  that  provides  operator  displays  and 
controls  shall  be  identical  to  the  corresponding  operational  compu¬ 
tational  equipment. 
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3.3.12  Space  Vehicle  Design  Requirements 

3.3.12.1  General  Structural  Design.  The  primary  support 
structure  for  the  space  equipment  shall  possess  sufficient  strength, 
rigidity,  and  other  characteristics  required  to  survive  the  critical 
loading  conditions  that  exist  within  the  envelope  of  handling  and 
mission  requirements.  It  shall  survive  those  conditions  in  a  manner 
that  assures  safety  and  that  does  not  reduce  the  mission  success 
probability.  The  primary  support  structure  of  the  space  equipment 
shall  be  electrically  conductive  to  establish  a  single-point  electrical 
ground.  The  structure  of  equipment  to  be  launched  in  the  STS  shall  be 
designed  to  meet  the  applicable  safety  requirements  of  NHB  1700.7. 

3.3.12.2  Strength  Requirements 

3.3.12.2.1  Yield  l.nad.  The  structure  shall  be  designed  to  have 
sufficient  strength  to  withstand  simultaneously  the  yield  loads, 
applied  temperature,  and  other  accompanying  environmental  phen¬ 
omena  for  each  design  condition  without  experiencing  yielding  or 
detrimental  deformation. 

3.3.12.2.2  Ultimate  Load.  The  structure  shall  be  designed  to 
withstand  simultaneously  the  ultimate  loads,  applied  temperature, 
and  other  accompanying  environmental  phenomena  without  failure. 

3.3.12.3  Stiffness  Requirements 

3.3.12.3.1  Dynamic  Properties.  The  structural  dynamic  prop- 
enies  of  the  equipment  shall  be  such  that  its  interaction  with  the 
space  vehicle  control  subsystem  does  not  result  in  unacceptable 
degradation  of  performance. 

3.3.12.3.2  Structural  Stiffness.  Stiffness  of  the  structure  and 
its  attachments  shall  be  controlled  by  the  equipment  performance 
requirements  and  by  consideration  of  the  handling,  launch,  and 
landing  environments.  Special  stowage  provisions  shall  be  used,  if 
required,  to  prevent  excessive  dynamic  amplification  during  transient 
flight  events  such  as  launch  or  landing. 

3.3.12.3.3  Component  Stiffness.  The  fundamental  resonant 
frequency  of  a  component  weighing  23  kilograms  or  less  shall  be  50 
Hertz  or  greater  when  mounted  on  its  immediate  support  structure. 
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3.3.12.4  Structural  Factors  of  Safety.  The  factor  of  safety  of 
the  structure  is  the  ratio  of  the  limit  load  to  the  allowable  load. 

3.3.12.4.1  Fliaht  Limit  Loads.  Available  options  for  structural 
design  are  listed  in  Table  I.  All  safety-related  structural  design 
requirements  shall  be  met. 

TABLE  I.  Structural  Design  Factors  of  Safety. 


Design 

Factor  of  Safety 
of  Limit  Loads 

Design  and  Test  Options 

Yield 

Ultimate 

(FSy) 

(FSu) 

Unmanned 

Events 

(FSu) 

Manned 

Events 

1, 

Dedicated  Test 

Article 

1.00 

1.25 

1.40 

2. 

Test  One  Flight 

Article 

1.25 

1.40 

1.40 

3. 

Proof  Test  Each 

Flight  Article 

1.10 

1.25 

1.40 

4. 

No  Static  Test 

1.60 

2.00 

2.25 

3.3.12.4.2  Pressure  Loads.  Factors  of  safety  for  pressure  loads 
shall  be  determined  individually  for  each  pressure  vessel,  based  on 
tests  to  establish  material  characteristics  and  an  analysis  of  life  re¬ 
quirements  and  other  environmental  exposure.  Proof  and  burst 
pressure  factors  shall  be  established  at  levels  that  ensure  structural 
integrity,  structural  life,  and  safety  throughout  all  phases.  The  values 
listed  in  Table  II  are  to  be  considered  as  limiting  lower  bounds. 

3.3.12.5  Design  Load  Conditions.  The  space  vehicle  equip¬ 
ment  shall  be  capable  of  withstanding  all  design  load  conditions  to 
which  it  is  exposed  in  all  mission  phases,  as  applicable:  ground, 
prelaunch,  erection,  post-launch,  boost,  orbit,  reentry,  and  landing. 
During  the  orbit  phase,  all  of  the  following  shall  be  considered: 
maneuvering  loads,  vehicle  spin,  meteoroid  environment,  radiation 
environment,  and  other  environmental  factors,  such  as  thermal  effects 
due  to  internal  heating,  solar  heating,  eclipses,  and  extreme  cold  due 
to  ambient  space  environment. 
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3.3.12.6  Space  Vehicle  Fluid  Subsystems 

3.3.12.6.1  Pressurized  Components.  Fluid  subsystems  and 
pressurized  components  shall  be  in  accordance  with  MIL-STD-1S22 
and  NHB  1700.7  (NASA).  For  all  space  equipment,  all  safety-related 
pressurized  component  design  requirements  shall  be  met. 

3.3.12.6.2  Tubing.  Tubing  shall  be  stainless  steel,  where 
practicable.  Tubing  joints  shall  be  thermal  welded  butt  joints,  where 
practicable.  Tubing  design  shall  incorporate  provisions  for  cleaning 
and  to  allow  proof  testing. 

3.3.12.6.3  Separable  Fittings.  Separable  fittings  shall  have 
redundant  sealing  surfaces,  such  as  double  "O"  rings,  and  be  of  the 
"parallel  loaded"  type.  "Parallel  loaded"  means  that  the  fitting  con¬ 
tains  a  compressed  element  which  exerts  outward  pressure  on  the 
other  elements  of  the  fitting  such  that  both  seals  are  maintained  even 
if  relaxation  occurs.  Separable  fittings  shall  have  provisions  for  lock¬ 
ing.  Separable  fittings  should  be  accessible  for  leak  tests  and  for 
torque  checks.  Separable  fittings  should  not  be  designed  or  assembled 
with  lubricants  or  fluids  that  could  cause  contamination  or  could  mask 
leakage  of  a  poor  assembly. 

3.3.12.7  Moving  Mechanical  Assemblies.  Deployment 
mechanisms,  sensor  mechanisms,  pointing  mechanisms,  drive 
mechanisms,  despin  mechanisms,  separation  mechanisms,  and  other 
moving  mechanical  assemblies  on  space  vehicles  shall  be  in 
accordance  with  MIL-A-83577. 

3.3.12.8  Explosive  Ordnance.  Explosive  ordnance  to  be 
installed  on  a  space  vehicle  shall  be  in  accordance  with  DOD-E-83578. 
All  safety-related  explosive  ordnance  design  requirements  shall  be 
met. 

3.3.12.9  Wiring  Harness.  The  electrical  wiring  harnesses 
between  space  components  shall  be  in  accordance  with  DOD-W-83575. 

3.3.12.10  Electronic  Components.  Electronic  components  for 
space  applications  shall  be  in  accordance  with  DOD-E-8983.  Electronic 
parts  for  space  applications  shall  be  in  accordance  with  MIL-STD- 
1547. 
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TABLE  n.  Factors  of  Safety  for  Pressurized  Components. 


Design  Acceptance  QualiBcation 


Comoonent 

Ultimate 

Solid  Rocket  Motor  Cases^ 

1.25 

I.IOC 

1.25C 

Pneumatic  Vessels^ 

2.00 

1.50C 

2.00C 

Lines,  Fittings,  and  Hoses 

Less  than  3.81  cm  diameter^ 

4.00 

2.00C 

4.00C 

3.81  cm  diameter  and  larger^ 

1.50 

I.IOC 

1.50C 

Other  Pressurized  Components 

2.50 

2.00C 

2.50C 

Notes: 

a.  All  pressure  vessels,  sealed  containers,  lines,  fittings, 
and  other  pressurized  components  of  equipment  to  be 
launched  in  the  STS  shall  be  designed  to  meet  the 
applicable  safety  requirements  of  NHB  1700.7  (NASA) 
and  SAMTO  HB  S-100  (designated  by  NASA  as  KHB 
1700.7). 

b.  Factors  of  safety  shown  are  minimum  values  applicable 
to  metallic  pressure  vessels  for  which  ductile  fracture 
mode  is  predicted  via  a  combination  of  stress  and 
fracture  mechanics  analyses.  Design  of  metallic 
pressure  vessels  for  which  brittle  fracture  mode  is 
predicted  by  these  analyses  shall  be  in  accordance 
with  fracture  mechanics  methodology  wherein  the 
proof  factor  as  well  as  the  design  ultimate  factor  of 
safety  shall  be  established  to  provide  a  minimum  of 
four  times  the  specified  service  life  against  mission 
requirements.  In  addition,  a  fracture  control  program 
shall  be  established  to  prevent  structural  failure  due 

to  the  initiation  or  propagation  of  flaws  or  crack- 
like  defects  during  fabrication,  testing,  and  service 
life. 

c.  No  yielding  is  permitted  at  acceptance  (proof)  test 
pressure  and  no  rupture  at  qualification  pressure. 

_ dL _ 3.81  cm  diameter  is  equivalent  to  1.5  inches  diameter. 


A-71 


SPEC  NUMBER  SS-01  APPENDIX  A 

15  OCT  91 


3.3.12.11  Solar  Arrays.  Solar  arrays  for  space  applications 
shall  be  in  accordance  with  MIL-S*83S76. 

3.3.12.12  Embedded _ Nonooerational  Elements.  Any  non- 

operational  elements  of  the  space  system  that  are  embedded  in  space 
elements,  such  as  self-test  circuitry,  computer  software,  or  other 
features  not  required  during  on-orbit  operations,  shall  be  designed  to 
the  applicable  requirements  of  the  operational  elements  in  which  they 
are  embedded. 

3.3.13  Operational  Ground  Eouioment:  General  Design 

Rfifluiremcnts 

3.3.13.1  General  Structural  Design.  The  primary  support 
structure  for  the  ground  equipment  shall  possess  sufficient  strength, 
rigidity,  and  other  characteristics  required  to  survive  the  critical 
loading  conditions  that  exist  within  the  envelope  of  handling  and 
mission  requirements.  The  primary  support  structure  shall  survive 
those  conditions  in  a  manner  that  assures  safety  for  the  mobile  or 
fixed  stations  as  applicable  and  that  does  not  reduce  the  mission 
success  probability.  The  primary  support  structure  of  the  equipment 
shall  be  electrically  conductive  and  shall  permit  the  implementation  of 
a  single-point  electrical  ground. 

3.3.13.2  Strength  Requirements 

3.3.13.2.1  Yield  Load.  The  structure  shall  be  designed  to  have 
sufficient  strength  to  withstand  simultaneously  the  yield  loads, 
applied  temperature,  and  other  accompanying  environmental  phe¬ 
nomena  for  each  design  condition  without  experiencing  yielding  or 
detrimental  deformation. 

3.3.13.2.2  Ultimate  Load.  The  structure  shall  be  designed  to 
withstand  simultaneously  the  ultimate  loads,  applied  temperature, 
and  other  accompanying  environmental  phenomena  without  failure. 

3.3.13.3  Stiffness  Requirements 

3.3.13.3.1  Dynamic  Properties.  The  structural  dynamic 
propenies  of  the  equipment  shall  be  such  that  its  interaction  with  the 
environment  does  not  result  in  unacceptable  degradation  of  perform¬ 
ance. 
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3.3.13.3.2  Slruclural  Stiftacss-  Stiffness  of  the  structure  and 
its  attachments  shall  be  controlled  by  the  equipment  performance 
requirements  and  by  consideration  of  the  handling,  transport,  and 
operational  environments.  Special  stowage  and  tie-down  provisions 
shall  be  used,  if  required,  to  prevent  excessive  dynamic  amplification 
during  transient  events  such  as  installation  and  transport. 


3.3.13.3.3  Component  Stiffness.  The  fundamental  resonant 
frequency  of  a  component  weighing  23  kilograms  or  less  shall  be  10 
Hertz  or  greater  when  mounted  on  its  immediate  support  structure. 


3.3.13.4  Structural  Factors  of  Safety.  The  factor  of  safety  of 
the  structure  is  the  ratio  of  the  limit  load  to  the  allowable  load. 


3.3.13.4.1  Transport  Limit  Loads.  Available  options  for 
structural  design  are  listed  in  Table  III.  All  safety-related  structural 
design  requirements  shall  be  met. 


TABLE  III.  Ground  Equipment  Structural  Design  Factors  of  Safety. 


Deisgn  Factor  of  Safety 
on  Limit  Loads 

Design  and  Test  Options 

Yield 

Ultimate 

1.  Static  Proof  Test  Each 

Air  Transportable  Anicle 

1.10 

1.40 

2.  No  Static  Test  (analysis 
only) 

1.60 

2.25 

3.3.13.4.2  Pressure  Loads.  Factors  of  safety  for  pressure 
loads  shall  be  determined  individually  for  each  pressure  vessel,  based 
on  tests  to  establish  material  characteristics  and  an  analysis  of  life 
requirements  and  other  environmental  exposure.  Proof  and  burst 
pressure  factors  shall  be  established  at  levels  that  ensure  structural 
integrity,  structural  life,  and  safety  throughout  all  phases.  The  values 
listed  in  Table  IV  are  to  be  considered  as  limiting  lower  bounds. 
Federal,  State,  and  local  safety  regulations  shall  be  met. 
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TABLE  rv 

Factors  of  Safety  for  Ground  Equipment  Pressurized  Components. 


Component^ 

Design 

Ultimate 

Acceptance  Qualification 
(Proof) 

Pneumatic  Vessels^ 

2.00 

1.50b 

2.00b 

Lines,  Fittings,  and  Hoses 

Less  than  3.81  cm  diameter^ 

4.00 

2.00b 

4.00b 

3.81  cm  diameter  and  larger^ 

1.50 

l.lOb 

1.50b 

Other  Pressurized  Components 

2.50 

2.00b 

2.50b 

Notes; 

a.  Factors  of  safety  shown  are  minimum  values  applic¬ 
able  to  metallic  pressure  vessels  for  which  ductile 
fracture  mode  is  predicted  via  a  combination  of  stress 
and  fracture  mechanics  analyses.  Design  of  metallic 
pressure  vessels  for  which  brittle  fracture  mode  is 
predicted  by  these  analyses  shall  be  in  accordance 
with  fracture  mechanics  methodology  wherein  the 
proof  factor  as  well  as  the  design  ultimate  factor  of 
safety  shall  be  established  to  provide  a  minimum  of 
four  times  the  specified  service  life  against  mission 
requirements.  In  addition,  a  fracture  control  program 
shall  be  established  to  prevent  structural  failure  due  to 
the  initiation  or  propagation  of  flaws  or  crack-like 
defects  during  fabrication,  testing,  and  service  life. 

b.  No  yielding  is  permitted  at  acceptance  (proof)  test 
pressure  and  no  rupture  at  qualification  pressure. 

c.  3.81  cm  diameter  is  equivalent  to  1.5  inches  diameter. 


3.3.13.5  Design  Load  Conditions.  The  equipment  shall  be 
capable  of  withstanding  all  design  load  conditions  to  which  it  is 
exposed. 
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3.3.13.5.1  Air  Transportation  Load  Factors.  The  load  factors 
applied  to  the  C-130,  C-141,  and  C-5  air  transport  environments  shall 
be  1.5. 


3.3.13.5.2  Ground  Transportation  Load  Factors.  The  ground 
transportation  load  factors  shall  be  l.S. 

3.3.13.6  Fluid _ Subsystems 

3.3.13.6.1  Pressurized  Components.  Fluid  subsystems  and 
pressurized  components  shall  be  in  accordance  with  MIL-STD-1522. 
For  all  equipment,  all  safety-related  pressurized  component  design 
requirements  shall  be  met. 

3.3.13.6.2  Tubing.  Tubing  shall  be  stainless  steel,  where 
practicable.  Tubing  joints  shall  be  thermal  welded  butt  joints,  where 
practicable.  Tubing  design  shall  incorporate  provisions  for  cleaning 
and  to  allow  proof  testing. 

3.3.13.6.3  Separable  Fittings.  Separable  fittings  shall  have 
provisions  for  locking.  Separable  fittings  should  be  accessible  for  leak 
tests  and  for  torque  checks.  Separable  fittings  should  not  be  designed 
or  assembled  with  lubricants  or  fluids  that  could  cause  contamination 
or  could  mask  leakage  of  a  poor  assembly. 

3.3.13.7  Electronic  Components.  Ground  electronic  equipment 
shall  be  in  accordance  with  MIL-E-4158.  Electronic  components  for 
ground  applications  shall  be  in  accordance  with  MIL-STD-1250.  The 
design  shall  avoid  use  of  incompatible  materials  such  as  that  given  in 
MIL-STD-1250,  Paragraph  5.13,  and  in  MIL-STD-171,  Paragraph  4.8. 

3.3.14  Nonoperational  Ground  Equipment:  General  Design 
Requirements.  Nonoperational  ground  equipment  is  ground 
equipment  that  is  used  off  line  in  such  areas  as  training,  maintenance, 
or  transportation  and  is  not  required  during  on-orbit  operations. 

3.3.14.1  Embedded  Nonoperational  Elements.  Any 
nonoperational  ground  equipment  that  is  embedded  in  operational 
ground  equipment,  such  as  self-test  circuitry,  computer  software,  or 
other  features  not  required  during  on-orbit  operations,  shall  be 
designed  to  the  applicable  requirements  of  the  operational  ground 
equipment  in  which  they  aic  embedded. 
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3.3.14.2  Other  Nonoperational  nround  Equipment 

3.3.14.2.1  Test  -Efluimnent-  Test  equipment  is  that  equipment 
required  to  support  the  maintenance,  repair,  and  checkout  of  the 
system  hardware  following  system  deployment.  To  the  extent 
practicable,  test  equipment  shall  be  designed  using  applicable 
commercial  practices.  Commercially  available  modules  shall  be  used 
to  the  extent  practicable. 

3.3.14.2.2  Trainers.  The  trainers  are  the  equipment  to  be  used 
for  the  training  of  system  operator  personnel.  To  the  extent  prac¬ 
ticable,  trainers  shall  be  designed  using  the  same  interfacing  controls, 
displays,  and  equipment  locations  as  occurs  operationally.  Trainers 
shall  be  designed  using  applicable  commercial  practices. 

3.3.15  General _ Construction _ RgquirgmgntS 

3.3.15.1  Processes  and  Controls  for  Space  Vehicle  Equip¬ 
ment.  Acceptance  and  flight  certification  of  space  equipment  is  based 
primarily  on  an  evaluation  of  data  from  the  manufacturing  process. 
The  manufacturing  process  for  space  equipment  shall  be  accomplished 
in  accordance  with  documented  procedures  and  process  controls  which 
assure  the  reliability  and  quality  required  for  the  mission.  These 
manufacturing  procedures  and  process  controls  shall  be  documented 
to  give  visibility  to  the  procedures  and  specifications  by  which  all 
processes,  operations,  inspections,  and  tests  are  to  be  accomplished  by 
the  supplier.  This  internal  contractor  documentation  shall  include  the 
name  of  each  part  or  component,  each  material  required,  the  point  it 
enters  the  manufacturing  flow,  and  the  controlling  specification  or 
drawing.  The  documentation  shall  indicate  required  tooling,  facilities, 
and  test  equipment;  the  manufacturing  check  points;  the  quality 
assurance  verification  points;  and  the  verification  procedures  corres¬ 
ponding  to  each  applicable  process  or  material  listed.  The  specifica¬ 
tions,  procedures,  drawings,  and  supporting  documentation  shall 
reflect  the  specific  revisions  in  effect  at  the  time  the  items  were  pro¬ 
duced.  These  flow  charts  and  the  referenced  specifications,  proce¬ 
dures,  drawings,  and  supporting  documentation  become  the  manufac¬ 
turing  process  control  baseline  and  shall  be  retained  by  the  supplier 
for  reference.  It  is  recognized  that  many  factors  may  warrant  making 
changes  to  this  documented  baseline;  however,  all  changes  to  the 
baseline  processes  used,  or  the  baseline  documents  used,  shall  be 
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recorded  by  the  supplier  following  establishment  of  the  manufac¬ 
turing  baseline  or  following  the  manufacture  of  the  first  item  or  lot  of 
items.  These  changes  provide  the  basis  for  flight  accreditation  of  the 
items  manufactured  or  of  subsequent  flight  items. 

The  manufacturing  process  and  control  documents  for  space 
equipment  shall  provide  a  supplier-controlled  baseline  that  assures 
that  any  subsequent  failure  or  discrepancy  analysis  that  may  be 
required  can  identify  the  specific  manufacturing  materials  and 
processes  that  were  used  for  each  item.  In  that  way,  changes  can  be 
incorporated  to  a  known  baseline  to  correc»  the  problems. 

3.3.15.1.1  Assembly  Lots.  To  the  extent  practicable,  parts  for 
use  in  space  equipment  shall  be  grouped  together  in  individual 
assembly  lots  during  the  various  stages  of  their  manufacture  to  assure 
that  all  devices  assembled  during  the  same  time  period  use  the  same 
materials,  tools,  methods,  and  controls.  Parts  and  devices  for  space 
equipment  that  cannot  be  tested  adequately  after  assembly  without 
destruction  of  the  item,  such  as  explosive  ordnance  devices,  some 
propulsion  components,  and  complex  electronics,  shall  have  lot 
controls  implemented  during  their  manufacture  to  assure  a  uniform 
quality  and  reliability  level  of  the  entire  lot.  Each  lot  shall  be 
manufactured,  tested,  and  stored  as  a  single  batch.  Sequential  lot 
numbers  that  indicate  the  date  of  manufacture  shall  be  assigned  to 
each  lot.  (Typically,  use  three  digits  for  the  day  of  the  year  and  two 
digits  for  the  year.) 

3.3.15.1.2  Contamination 

3.3.15.1.2.1  Fabrication  and  Handling.  Fabrication  and 
handling  of  space  equipment  shall  be  accomplished  in  a  clean  environ¬ 
ment.  Attention  shall  be  given  to  avoiding  nonparticulate  (chemical) 
as  well  as  particulate  air  contamination.  To  avoid  safety  and  contam¬ 
ination  problems,  the  use  of  liquids  shall  be  minimized  in  areas  where 
initiators,  explosive  bolts,  or  any,  loaded  explosive  devices  are  exposed. 

3.3.15.1.2.2  Device  Cleanliness.  The  particulate  cleanliness  of 
internal  moving  subassemblies  shall  be  maintained  to  at  least  level 
500  as  defined  in  MIL-STD-1246.  External  surfaces  shall  be  visibly 
clean. 


3.3.15.1.2.3  Outeassing.  Items  that  might  otherwise  produce 
deleterious  outgassing  while  on  orbit  shall  be  baked  for  a  sufficient 
time  to  drive  out  all  but  an  acceptable  level  of  outgassing  products 
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prior  to  installation  in  the  experiment  or  space  vehicle.  (See  Para¬ 
graph  6.1.1  herein.)  Analytical  contamination  models  shall  be  used  to 
evaluate  performance  impacts  of  outgassing  on  adjacent  critical 
equipment. 


3.3.15.1.3  Electrostatic  Discharge.  Appropriate  provisions 
stated  in  DOD-HDBK-263  shall  be  used  to  avoid  and  to  protect  against 
the  effects  of  static  electricity  generation  and  discharge  in  areas  con¬ 
taining  electrostatic  sensitive  devices  such  as  microcircuits,  initiators, 
explosive  bolts,  or  any  loaded  explosive  device.  Both  equipment  and 
personnel  shall  be  grounded. 

3.3.15.1.4  Mechanical  Interfaces.  Where  practicable,  a 
common  interface  drill  template  shall  be  used  to  assure  correct 
mechanical  mating,  particularly  for  interfaces  external  to  the 
equipment. 


3.3.15.2  Processes  and  Controls  for  Ground  Equipment. 

The  manufacturing  processes  and  controls  for  ground  equipment  shall 
be  selected  and  documented  using  the  same  criteria  as  used  in  the 
manufacture  of  similar  commercial  equipment. 

3.4  DOCUMENTATION 

The  design  and  manufacturing  processes  for  space  vehicle  equip¬ 
ment  shall  be  documented,  and  the  documents  maintained  current,  to 
give  visibility  to  the  designs,  procedures,  and  specifications  by  which 
all  processes,  operations,  inspections,  and  tests  are  accomplished.  The 
design  documentation  shall  include  specifications,  assembly  and 
detailed  drawings,  part  lists,  test  procedures,  operating  procedures, 
maintenance  procedures,  and  supporting  documentation.  The  manu¬ 
facturing  documentation  shall  include  the  name  of  each  part  or  com¬ 
ponent,  each  material  required,  the  point  it  enters  the  manufacturing 
flow,  the  controlling  specification  or  drawing,  required  tooling, 
required  facilities,  required  test  equipment,  the  manufacturing  check 
points,  the  quality  assurance  verification  points,  and  the  verification 
procedures  corresponding  to  each  applicable  process  or  material  listed. 
The  design  and  manufacturing  process  and  control  documents  for 
space  equipment  shall  provide  a  supplier-controlled  baseline  that 
assures  that  any  subsequent  failure  or  discrepancy  analysis  that  may 
be  required  can  identify  the  specific  design  and  specific  manufac¬ 
turing  materials  and  processes  that  were  used  for  each  item.  In  that 
way,  changes  can  be  incorporated  to  a  known  baseline  to  correct  the 
problems. 
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The  design  of  ground  equipment  shall  be  documented,  and  the 
documents  maintained  current,  to  give  visibility  to  the  designs  and  to 
each  of  the  applicable  procedures.  The  documentation  of  ground 
equipment  shall  include  speciHcations,  detailed  drawings,  assembly 
drawings,  installation  drawings,  part  lists,  computer  software  designs, 
computer  software  code,  computer  software  test  tools,  all  test  pro¬ 
cedures,  operating  procedures,  maintenance  procedures,  training 
materials,  and  other  supporting  documentation.  The  documentation 
for  ground  equipment  shall  be  in  sufficient  detail  to  provide  a 
supplier-controlled  baseline  that  assures  reliable  operations  and 
timely  maintenance  of  the  space  system. 

3^  LOGISTICS 

Equipment  designs  shall  be  based  upon  minimizing  the  system  life 
cycle  cost,  assuming  the  contractors  provide  the  logistic  support  for 
the  system  for  the  service  life  of  the  system. 

3.5.1  Support  Concept.  Ground  equipment  designs  shall  be 
based  on  using  operator  maintenance  to  the  maximum  extent  prac¬ 
ticable.  Operator  maintenance  includes  self  tests,  simple  fault 
diagnosis  and  fault  isolation,  and  surface  cleaning  as  required  by 
environmental  conditions.  Ground  equipment  designs  may  be  based 
on  using  organizational  level  maintenance  and  intermediate  level 
maintenance  for  more  complex  fault  diagnosis  and  fault  isolation,  for 
removal  and  replacement  of  complete  assemblies  or  line-replaceable 
units,  for  preventive  maintenance,  for  corrosion  control,  for  alignment, 
and  for  calibration.  Depot-level  maintenance  shall  be  minimized. 

3-5.2  Siippflrt _ Facilitits 

3.5.2.1  Hardware  Support.  Ground  equipment  designs  shall  be 
based  on  using  government-furnished  facilities  for  housing  hardware 
spares,  test  equipment,  maintenance  equipment,  and  maintenance 
personnel  doing  maintenance  or  repair  tasks. 

3.5.2.2  CSCl  Support.  The  Computer  Software  Maintenance 
Resources  to  be  developed  as  required  by  Paragraph  3.3.11.2  shall  be 
located  in  a  government-furnished  facility  for  computer  software 
maintenance  during  the  operational  life  of  the  system.  (See  Paragraph 
3.3.11.2.) 


3.5.3  Supply.  Ground  equipment  designs  shall  be  based  on  using 
contractor  supply  support  to  provide  the  initial  supply  of  spares  and 
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consumable  materials,  resupply  of  spares  and  consumable  materials, 
inventory  management,  property  accountability,  and  computer  data 
processing  spares  and  consumable  materials. 

3.6  PERSONNEL  AND  TRAINING 

3.6.1  Personnel.  Ground  equipment  designs  shall  be  based  on 
using  a  minimum  number  of  operator  and  maintenance  personnel. 

The  initial  operators  and  maintenance  personnel  shall  be  professional- 
level  contractor  personnel. 

3.6.2  Training.  Ground  equipment  designs  shall  be  based  on 
minimizing  the  special  training  of  operator  and  maintenance  person¬ 
nel.  Training  of  the  initial  complement  of  operators  and  maintenance 
personnel  shall  be  accomplished  by  the  contractor  by  formal  class¬ 
room  instruction  covering  familiarization  with  the  system,  hardware 
and  software  subsystems,  and  real-time  operations.  Additional  on- 
the-job  training  for  the  initial  complement  of  operators  and  mainte¬ 
nance  personnel  shall  cover  all  aspects  of  equipment  operations  and 
maintenance.  The  equipment  maintenance  training  program  shall 
make  maximum  use  of  vendor  training  courses.  Training  of  the  initial 
complement  of  operators  and  maintenance  personnel  shall  be  used  to 
develop  documentation,  training  aids,  and  other  material  that  may  be 
of  value  in  training  additional  complements  of  operators  and  main¬ 
tenance  personnel. 

3.7  CHARACTERISTICS  OF  SUBORDINATE  ELEMENTS 

3.7.1  Requirements  Allocated  to  Subtier  Elements 

3.7.1.1  Space  Vehicle  System  Segment.  (TBS) 

3.7. 1.2  Ground  Terminal  System  Segment.  (TBS) 

3.7.1.3  Data  Reduction  System  Segment.  (TBS) 

3.7.1.4  Other  System  Segments.  (TBS) 

3.7.2  Internal  Interface  Requirements.  (TBS) 

3.7.2. 1  Internal  Interface  Identification.  (TBS) 

3.7.2.2  Internal  Hardware  CI-to-Hardware  Cl  Inter¬ 
faces.  (TBS) 
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3.7.2.3  Internal  Hardware  ri.to-CofnDuter  Software  Cl 
Interfaces.  (TBS) 

3.7.2.4  Internal  Computer  Software  Cl-to-Computer  Soft¬ 
ware  Cl  Interfaces.  (TBS) 

3.73  Requirements  Traceability  Matrices.  (Not  applicable.) 

[Note:  For  guidance  in  tracing  the  allocation  of  requirements,  the 
system  function(s)  performed  by  each  hardware  Cl  and  each  computer 
software  Cl  may  be  summarized  in  Requirements  Traceability  Matri¬ 
ces  such  as  shown  in  Appendix  B  of  this  specification.  This  is  an 
optional  requirement  as  far  as  the  specification  is  concerned;  however, 
other  contract  provisions  may  require  the  completion  of  the  Require¬ 
ments  Traceability  Matrices  by  the  contractor.  In  that  case  it  could  be 
referenced  here.  If  the  Requirements  Traceability  Matrices  is  pre¬ 
pared  as  Document  345X  that  is  referenced  here.  Document  345X  then 
would  be  added  to  the  list  of  references  in  Section  2.  If  the  contractor 
is  required  to  prepare  or  update  the  matrix,  that  requirement  must  be 
listed  in  the  CDRL.] 

3.8  PRECEDENCE 

3.8.1  Conflicts.  In  the  event  of  conflict  between  the  documents 
referenced  herein  and  the  contents  of  this  specification,  the  contents 
of  this  specification  shall  be  considered  the  superseding  requirements, 
unless  the  conflict  involves  external  interface  loquirements  of  the 
system.  In  the  event  of  a  conflict  involving  the  external  interface 
requirements  of  the  system,  such  as  a  conflict  with  equipment 
external  to  the  system  being  specified,  or  in  the  event  of  any  other 
unresolved  conflict,  such  as  a  conflict  with  govemment-fumished 
property,  the  contracting  officer  shall  be  notified,  and  the  order  of 
precedence  shall  be  as  directed  by  the  contracting  officer. 

3.8.2  Requirement  Weighting  Factors.  The  requirements 
stated  herein  are  a  composite  of  the  designs,  items,  and  practices 
found  to  be  cost  effective  for  high-reliability  devices  used  in  space 
systems.  Because  of  the  broad  scope  of  these  requirements,  all 
requirements  stated  are  not  of  equal  importance  or  weight.  They 
have  been  divided  into  four  categories  of  imponance  ranging  from 
requirements  that  are  imposed  on  all  applications  to  examples  of 
acceptable  designs,  items,  and  practices.  The  relative  weighting 
factors  for  the  requirements  are  incorporated  so  they  can  be  a 
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consideration  in  making  trade  studies  of  alternatives.  The  weighting 
factors  that  are  incorporated  in  the  specification  are: 

a.  Weighting  factor  ’'a”.  "Shall"  designates  the  most  important 
weighting  level,  the  mandatory  requirements.  Unless  modified 
by  the  contract,  the  "shall”  requirements  constitute  the  firm 
contractual  compliance  requirements.  Any  deviations  from 
these  contractually  imposed  mandatory  requirements  require 
the  approval  of  the  contracting  ofHcer. 

b.  Weighting  factor  "b".  "Shall,  where  practicable,"  designates 
requirements,  items,  or  practices  at  the  second  weighting  level. 
Alternative  designs,  items,  or  practices  may  be  used  for  specific 
applications,  when  the  use  of  the  alternative  is  substantiated 
by  documented  technical  trade  studies.  These  trade  studies 
shall  be  made  available  for  review  when  requested  or  provided 
to  the  government  in  accordance  with  the  contract  provisions. 
Unless  required  by  other  con-tract  provisions,  noncompliance 
with  the  "shall,  where  practicable,"  requirements  does  not 
require  approval  of  the  contracting  officer. 

c.  Weighting  factor  "c".  "Preferred"  or  "should"  designates  the 
third  weighting  level.  Unless  required  by  other  contract 
provisions,  noncompliance  with  these  preferred  requirements 
does  not  require  approval  of  the  contracting  officer  and  does 
not  require  documented  technical  substantiation. 

d.  Weighting  factor  "d".  "May"  designates  the  lowest  weighting 
level.  In  some  cases,  these  "may"  requirements  are  stated  as 
examples  of  acceptable  designs,  items,  and  practices.  Unless 
required  by  other  contract  provisions,  noncompliance  with  the 
"may"  requirements  does  not  require  approval  of  the  contrac¬ 
ting  officer  and  does  not  require  documented  technical  sub¬ 
stantiation. 

3.8.3  Life  Cycle  Cost.  System  life  cycle  cost  estimates  shall  be 
used  as  an  additional  engineering  tool  to  establish  the  order  of  prece¬ 
dence  among  alternatives.  Although  all  of  the  requirements  are  believed 
essential,  the  designs  shall  consider  the  relative  importance  of  the 
requirements  to  be  such  that  minimizing  system  life  cycle  cost  is  as 
important  as  meeting  the  system  performance  and  physical  character¬ 
istic  requirements  stated.  All  other  system  requirements  shall  be 
considered  of  less  importance  than  the  system  life  cycle  cost,  the  system 
performance,  and  the  physical  characteristics  specified.  (TBS) 
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3.8.4  SuDDlementarv  Specifications  and  Standards.  If  the 
documents  referenced  in  this  specification  do  not  provide  the  contrac¬ 
tually  required  reliability,  quality  level,  or  technical  performance,  they 
should  be  interpreted  as  being  referenced  to  limit  the  variety  of  the 
physical  and  functional  parameters  to  the  extent  practicable.  In  those 
cases,  the  referenced  specifications  shall  be  the  basis  of  contractor 
specifications  that  would  add,  delete,  or  change  specific  requirements. 

The  use  of  contractor  specifications  shall  not  constitute  waiver  of 
government  inspection  requirements. 

3.9  QUALIFICATION 

Qualification  is  required  for  each  space  vehicle  design,  for  each  space 
vehicle  component  design,  and  for  each  electronic  part  type  used  in  the 
space  vehicle  design.  Qualification  also  is  required  for  each  computer 
software  configuration  item.  The  contracting  officer  grants  qualification 
status  for  the  items  as  used  in  the  specific  space  system  based  on  the 
results  of  the  qualification  tests  specified  in  Section  4.  Unless  specified, 
qualification  is  not  required  for  ground  equipment. 

3.10  STANDARD  SAMPLE  (Not  applicable) 

3.11  PREPRQDUCTIQN  SAMPLE.  PERIODIC  PRODUCTION  SAMPLE, 
PILOT.  OR  PILOT  LOT  (Not  applicable) 
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SECTION  4 

QUALITY  ASSURANCE  PROVISIONS 


4.1  RESPONSIBILITY  FOR  INSPECTION 

Unless  otherwise  specified  in  the  contract  or  purchase  order,  the 
contractor  is  responsible  for  the  performance  of  all  inspection  and  test 
requirements  specified  herein.  The  government  reserves  the  right  to 
perform  any  of  the  inspections  set  forth  in  the  specification  where 
such  inspections  are  deemed  necessary  to  assure  that  supplies  and 
services  conform  to  prescribed  requirements. 

4.1.1  Philosophy  of  Testing.  Because  the  quality  assurance 
requirements  for  space  systems  can  have  a  major  cost  and  schedule 
impact,  considerable  detail  is  provided  in  this  system  specification. 
Because  the  requirements  are  different,  general  boilerplate  test  and 
inspection  requirements  applicable  to  operational  elements  of  the 
system  are  separated  from  those  applicable  to  nonoperational  ele¬ 
ments.  The  identified  test  and  inspection  requirements  are  for  the 
operational  elements  of  the  space  system  unless  specifically  stated 
otherwise.  The  test  requirements  for  the  operational  elements  are 
separated  into  those  applicable  to  space  elements  (space  vehicle 
equipment)  and  those  applicable  to  nonspace  elements  (typically 
ground  equipment  and  computer  software).  The  test  requirements  for 
the  nonoperational  elements  of  the  space  system  (elements  not  re¬ 
quired  for  on-orbit  suppon)  generally  are  functional  tests  conducted 
after  installation  to  verify  performance  requirements.  Nonoperational 
elements  of  the  space  system  that  are  embedded  in  operational  ele¬ 
ments,  such  as  self-test  features,  shall  be  designed  and  tested  to  the 
applicable  requirements  of  the  operational  elements  in  which  they  are 
embedded. 

The  extremely  high  cost  of  an  on-orbit  space  vehicle  failure  means 
that  all  operational  elements  of  the  space  system  must  be  designed 
and  fabricated  to  assure  high  reliability.  Testing  requirements  of  the 
space  elements  (primarily  the  space  vehicle  and  its  components)  are 
perhaps  the  most  stringent  requirements.  The  specified  tests  provide 
general  screening  checks,  but  they  are  necessarily  insufficient  to 
absolutely  assure  the  reliability  of  the  space  vehicle.  In-process 
screening  tests,  including  stress  screening,  must  be  used  at  the  parts, 
materials,  and  subassembly  levels,  and  at  all  subtier  levels  where 
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appropriate,  to  assure  a  reliable  space  vehicle.  The  acceptance  tests  at 
the  space  vehicle  level  provide  a  final  check  for  any  gross  errors.  In 
addition,  the  nonspace  elements  of  the  system  required  to  support  on- 
orbit  operations  (ground  equipment  and  computer  software)  shall  be 
adequately  tested  to  assure  satisfactory  support  of  the  space  missions. 
Finally,  the  prelaunch  system-level  tests  and  inspections  are  con¬ 
ducted  to  verify  at  the  last  opponunity  that  each  critical  path  in  the 
launch  system,  in  the  on-orbit  system,  and  in  the  reentry  system  is 
satisfactory. 

In  general,  the  test  philosophy  for  ground  equipment  and  com¬ 
puter  software  for  a  space  system  is  the  same  as  for  the  space 
equipment,  but  the  details  differ.  Operational  ground  equipment  and 
computer  software  also  are  tested,  starting  at  the  lowest  levels  of 
assembly,  and  progressively  tested  at  each  level  through  to  the  final 
system  level,  as  required  to  assure  mission  success.  However,  for 
ground  equipment,  the  tests  generally  are  not  as  detailed,  and  greater 
emphasis  is  placed  on  the  system-level  tests.  The  test  and  inspection 
requirements  applicable  to  nonoperational  elements  of  the  system  are 
even  less  stringent,  typically  consisting  of  functional  checks  to  verify 
nominal  performance  after  installation. 

Proper  design  requires  that  items  at  each  level  of  assembly  have 
broader  parameter  tolerances  and  narrower  environmental  ranges 
than  the  subtier  items  that  are  used  in  its  fabrication.  In  that  way, 
manufacturing  defects  can  be  screened  out  at  the  lowest  level  of 
assembly  possible,  and  items  that  pass  subtier  screening  tests  should 
not  be  expected  to  fail  during  subsequent  tests  at  higher  levels  of 
assembly.  Also,  critical  parameters  that  cannot  be  measured  accu¬ 
rately  at  higher  levels  of  assembly  must  be  evaluated  at  lower  levels 
of  assembly.  This  usually  means  that  some  form  of  stress-screening 
tests  are  cost  effective  at  subtier  levels.  For  a  particular  system 
design  or  for  a  particular  contractor,  the  optimum  set  of  quality 
assurance  provisions  may  differ  from  those  stated  herein.  A  different 
balance  using  more  subtier  testing  and  less  vehicle  or  system-level 
testing  may  be  cost  effective;  however,  any  reduction  in  the  specified 
quality  assurance  provisions  requires  contracting  officer  approval. 

Note  that  part  screening  usually  is  conducted  using  the  maximum 
range  of  design  or  qualification  conditions  in  the  pan  specifications. 
Assuming  proper  applications  of  the  parts,  those  conditions  always 
would  be  more  severe  than  the  conditions  specified  for  subassembly 
or  component  screening.  Since  the  subassembly  or  component  tests  do 
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not  duplicate  the  stringent  conditions  of  part-level  testing,  they  should 
never  be  viewed  as  a  substitute  for  part-level  screening. 

4.1.2  Location  of  Testing.  Except  as  otherwise  specified  in  the 
contract  or  order,  tests  and  evaluations  of  the  space  elements  may  be 
conducted  at  in-plant  test  facilities,  which  may  include  subcontractor's 
facilities,  at  a  government-approved  test  bed,  or  at  any  other  appro¬ 
priate  test  facility  selected  by  the  contractor.  The  part,  material,  and 
software  unit  development  tests  and  evaluations.  Step  1  tests,  and 
Step  2  tests  of  ground  equipment  and  of  computer  software  also  may 
be  conducted  at  in-plant  test  facilities,  which  may  include  subcon¬ 
tractor's  facilities,  at  a  government-approved  test  bed,  or  at  any  other 
appropriate  test  facility  selected  by  the  contractor.  However,  when 
testing  is  performed  at  an  operational  government  facility, 
government-approved  formal  test  plans  and  procedures  may  be 
required. 

Where  practicable.  Step  3  integrated  system  tests  of  ground  equip¬ 
ment  and  of  computer  software  shall  be  performed  on  integrated  CIs 
installed  in  an  operational  system.  Whenever  possible,  these  tests 
shall  be  conducted  at  a  specified  target  site  with  the  support  of  the 
operational  personnel.  A  development  test  bed  approved  by  the 
Acquisition  Activity  as  sufficiently  simulating  the  operational  system 
capability  for  test  purposes  may  be  used  for  Step  3  integrated  system 
tests,  if  target  sites,  operational  complexes,  or  other  suitable  opera¬ 
tional  support  areas  are  not  available.  Step  4  and  Step  5  tests  shall  be 
performed  on  an  operational  system  at  the  specified  target  site. 

Prelaunch  system-level  inspections  and  tests  shall  be  conducted  on 
the  operational  system  with  the  space  vehicle  mated  with  the  launch 
vehicle,  using  operational  interfaces  to  the  extent  practicable. 

4.2  SPECIAL  TESTS  AND  EXAMINATIONS 

4.2.1  Classiricafion  of  Inspections  and  Tests.  The  categories 
listed  are  intended  to  encompass  all  tests  and  inspections  required 
during  the  system  acquisition.  The  tests  and  inspections  specified 
herein  are  classified  as  follows: 
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4.2.1.1.1  Inspections  and  Tests  of  Space  Elements. 

(4. 2. 2.1) 

a.  Parts,  materials,  and  process  controls  (4.2.2. 1.1) 

b.  Design  verification  tests  (4.2.2. 1.2) 

c.  Qualification  tests  (4.2.2. 1.3) 

d.  Acceptance  tests  (4.2.2. 1.4) 

e.  Service  life  verification  tests  (4.2.2. 1.5) 

4.2.1.1.2  Inspections  and  Tests  of  Ground  Equipment  and 

Cflmputgr  Software-  (4.2.2.2) 

a.  Pan,  Material,  and  Software  Unit  Development  Tests  and 
Evaluations  (4.2.2.2.1) 

b.  Step  1  -  Component  Test  and  Evaluation  (Development) 
(4.2.2.2.2) 

c.  Step  2  -  Configuration  Item  Compliance  Tests  (Qualification 
and  Acceptance)  (4.2.2.2.3) 

Step  2.1  -  Single  Cl  or  CSCI  Compliance  Tests  (4.2.2.2.3.1) 
Step  2.2  -  Combined  CI/CSCI  Compliance  Tests  (4.2.2.2.3.2) 

d.  Step  3  -  Integrated  System  Testing  (4.2.2.2.4) 

e.  Step  4  -  Initial  Operational  Test  and  Evaluation  (lOTE) 

(4.2.2.2.5) 

f.  Step  5  -  Follow-on  Operational  Test  and  Evaluation  (FOT&E) 

(4.2.2.2.6) 
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4.2.2  Inspections  and  Tests  of  Operational  Elements  of 
the  Qn-orbit  Space  S.YStem 

4.2.2.1  Inspections  and  Tests  of  the  Space  Elements 

4.2.2.1.1  Space  Vehicle  Parts.  Materials,  and  Process 
Controls.  Pans,  materials,  and  process  controls  are  to  be  applied 
during  production  of  all  items  to  ensure  that  a  reliable  system  is 
fabricated.  All  pans  and  materials  shall  be  adequately  controlled  and 
inspected  prior  to  assembly.  During  fabrication  of  the  space  vehicle 
and  other  space  equipment,  the  tools  and  processes,  as  well  as  pans 
and  materials,  shall  be  adequately  controlled  and  inspected  to  assure 
compliance  with  the  approved  manufacturing  processes  and  controls. 
Quality  assurance  requirements  included  in  specifications  referenced 
in  Section  3  of  this  specification  are  considered  incorporated  as 
requirements  of  this  section  and  should  be  met  for  the  applicable 
classes  of  equipment. 

4.2.2.1.1.1  Space  Vehicle  Records.  Records  documenting  the 
status  of  the  space  vehicle  and  other  space  equipment  shall  be  main¬ 
tained  following  assignment  of  serial  numbers.  Each  space  item  shall 
have  inspection  records  and  test  records  maintained  by  serial  number 
to  provide  traceability  from  system  usage  to  production  lot  data  for 
the  devices.  Complete  records  shall  be  maintained  for  the  space  items 
and  shall  be  available  for  review  during  the  service  life  of  the  system. 
The  records  shall  indicate  all  relevant  test  data,  all  rework  or  modi¬ 
fications,  and  all  installations  and  removals  for  whatever  reason. 
Ground  equipment  items  shall  have  inspection  records  and  test 
records  maintained  by  serial  number  for  the  service  life  of  the  item. 

4.2.2.1.1.2  Space  Vehicle  Manufacturin£  Screens.  Each 
critical  subassembly,  component,  experiment,  and  vehicle  shall  be 
subjected  to  in-process  manufacturing  and  assembly  screens  to  assure 
compliance  with  the  specified  requirements  to  the  extent  practicable. 
Compliance  with  the  documented  process  controls,  documented 
screening  requirements,  required  hardware  configuration,  and  general 
workmanship  requirements  shall  be  verified.  At  each  level  of  assem¬ 
bly,  each  completed  unit  shall  be  subjected  to  visual  inspection  to 
assure  that  it  is  free  of  obvious  defects  and  is  within  specified  physical 
limits. 


4.2.2.1.1.3  Nonconforming  Material.  Nonconforming 
material,  components,  or  assemblies  that  do  not  meet  the  established 
tolerance  limits  set  for  the  acceptance  limits  in  the  in-process  screens 
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shall  be  rejected  for  use.  Any  rejected  material,  component,  or  assem¬ 
bly  may  be  reworked  and  rescreened  in  accordance  with  established 
procedures  if  system  reliability  is  not  jeopardized.  Nonconforming 
material  or  assembled  units  in  each  lot  may  be  reworked  and  re¬ 
screened  in  accordance  with  established  procedures  if  the  rework  is 
not  so  extensive  as  to  jeopardize  the  lot  identity  of  the  material  or 
assembled  unit.  If  the  reworked  material  or  assembled  unit  subse¬ 
quently  passes  the  in-process  screens,  it  again  can  be  considered  part 
of  the  lot.  Reassignment  of  assembled  units  to  a  different  lot  shall  not 
be  made.  Nonconforming  material  or  assembled  units  that  do  not 
satisfy  these  rework  criteria  shall  be  considered  scrap. 

4.2.2.1.2  Space  Vehicle  Design  Verification  Tests.  Design 
veriHcation  testing  shall  be  performed  to  demonstrate  compliance  of 
new  designs  or  of  modified  designs  with  the  specified  performance 
margins.  Test  units  shall  be  sufficiently  similar  to  the  hnal  production 
units  so  as  not  to  jeopardize  the  validity  of  the  test  results. 

4.2.2.1.2.1  Engineering  Tests 

4.2.2.1.2.1.1  Verification of  Nonoperating  Constraints. 

The  effects  of  nonoperational  environments  on  the  space  equipment 
may  be  determined  by  nonoperating  development  tests.  These  tests 
would  be  used  to  identify  fabrication,  storage,  handling,  transpor¬ 
tation,  installation,  and  launch  preparation  constraints  or  controls  that 
might  be  necessary.  Note  that  approval  of  the  contracting  officer  is 
required,  if  it  is  necessary  to  provide  special  nonoperating  environ¬ 
mental  controls  other  than  those  specified  herein. 

4.2.2.1.2.1.2  Development  Tests.  Typically,  breadboard  or 
prototype  hardware  is  used  for  development  tests.  When  cost 
effective,  flight  hardware  may  be  utilized  for  the  development  test 
program.  The  development  tests  are  performed  as  required  to  yield 
information  necessary  to  determine: 

a.  Design  feasibility 

b.  Adequacy  of  basic  design  approaches 

c.  Functional  parameters 

d.  Thermal  and  structural  data  with  particular  emphasis  on 
deployment,  separation,  latching  mechanisms,  clearances. 
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c. 


f. 


g- 


h. 


structural  dynamic  characteristics,  and  math  model 
verification 

Mass  properties 

Packaging  and  fabrication  techniques 
Stabilization  performance 
EMC  including  TEMPEST 


i.  Safety 

j.  Cleanliness  requirements  and  contamination  compatibility 


4.2.2.1.2.1.3  Modal  Survey.  Modal  survey  tests  are  required 
for  large  equipment  (see  MIL-STD-1540).  The  flight  hard- ware,  or 
dynamically  simulated  hardware,  including  attachment  and  support 
hardware,  is  the  test  article.  All  natural  modes  of  vibration  at 
frequencies  below  50  Hz  shall  be  determined. 


4.2.2.1.2.1.4  Static  Loads.  A  static  loads  test  as  specified  in 
MIL-STD-1540  shall  be  performed  on  each  vehicle  or  experiment. 


4.2.2.1.2.1.5  Thermal  Balance.  The  flight  vehicle  or  experi¬ 
ment  shall  be  subjected  to  a  thermal  balance  test  as  specified  in  Para¬ 
graph  6.2.8  of  MIL-STD-1540.  The  test  shall  include  both  maximum 
and  minimum  power  dissipation  modes.  If  heat  pipes  are  included, 
the  attitude  of  the  equipment  shall  be  such  as  to  not  bias  the  test 
measurements.  A  thermal  math  model  shall  be  used  to  correlate 
pretest  temperature  predictions  with  the  test  data  from  the  thermal 
balance  test.  As  a  goal,  correlation  of  test  results  to  the  thermal  model 
predictions  shall  be  within  ±  3  degrees  C.  The  correlated  thermal  math 
model  then  is  used  to  make  final  temperature  predictions  for  all 
mission  phases  and,  hence,  verify  the  thermal  margins  required  by 
MIL-STD-1540. 


4.2.2. 1. 2.1.6  Magnetic  Mapping.  If  applicable,  a  magnetic 
mapping  on  the  assembled  vehicle  or  experiment  shall  be  conducted 
to  provide  remnant,  stray,  and  induced  magnetic  field  data. 


4.2.2.1.2.1.7  Current  Margin.  Electrical  current  margins  on  all 
electroexplosive  ordnance  circuits  shall  be  demonstrated.  The  test 
shall  verify  that  no  less  than  the  minimum  recommended  firing 
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current  (twice  all-fire)  will  be  delivered  to  the  electroexplosive 
devices  under  worst  conditions  of  minimum  voltage  and  maximum 
circuit  and  electroexplosive  device  resistance.  The  test  also  shall 
verify  that  the  maximum  current  delivered  to  the  electroexplosive 
device  does  not  exceed  its  maximum  qualified  firing  current  under 
worst  conditions  of  maximum  voltage  and  minimum  circuit  and 
electroexplosive  device  resistance. 

4.2.2.1.2.1.8  Mechanism  Motion  Test.  The  erection, 
deployment,  latching,  and  jettison  features  shall  be  tested  to 
demonstrate  adequate  functioning  under  worst  case  environments. 

4.2.2.1.2.1.9  Shock.  Equipment  susceptible  to  shock  shall  be 
evaluated  for  bench  handling  (nonoperating)  and,  while  operating,  for 
possible  pyroshock  effects. 

4.2.2.1.2.1.10  Crash  Safety  (Nonoperating).  Although 
analysis  usually  is  adequate  for  Shuttle  missions,  a  demonstration  may 
be  used  to  show  that  the  equipment  design  complies  with  the  crash 
safety  criteria:  i.e.,  the  equipment  and  its  mounting  attachments  shall 
not  become  detached,  create  a  hazard  to  personnel  or  to  the  Shuttle 
Orbiter,  or  prevent  egress  from  a  crashed  vehicle.  Operating  perform¬ 
ance  is  not  required  during  or  after  this  test,  so  a  nonoperating  mass 
simulator  may  be  used.  Compliance  to  the  fracture  control  plan  is 
required. 

4.2.2.1.2.1.11  Out£assing.  Outgassing  evaluation  tests  are 
required  for  materials,  components,  and  subsystems  whose  outgassing 
properties  are  not  known.  (See  Paragraph  6.1.1  in  this  specification.) 


4.2.2.1.2.2 

Preliminarv 

Design 

Qualification 

Tests. 
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4.2.2.1.2.3 

Reliabilitv 
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Component 
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Qualification  tests  shall 

be 

performed  to  demonstrate,  to  the  extent  it  is  practicable,  that  space 
vehicle  components  that  are  manufactured  in  accordance  with  the 
approved  processes  and  controls  meet  the  specified  design  require- 
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ments.  Except  as  specified  herein,  the  first  article  manufactured  of 
each  type  shall  be  acceptance  tested  and  then  qualification  tested  in 
accordance  with  the  component  level  tests  in  MIL-STD-1540.  The 
6-dB,  10-degree  C,  or  other  design  factors  of  safety  or  margins  that 
are  included  in  the  design  requirements  specified  herein  include  test 
condition  tolerances  that  are  those  allowed  in  MIL-STD-1S40.  When 
the  actual  test  tolerances  are  less  than  those  specified  in  MIL-STD- 
1540,  the  qualification  test  levels  may  be  reduced  appropriately  in 
accordance  with  provisions  specified  in  MIL-STD-1540.  All  qualifi¬ 
cation  tests  shall  be  conducted  with  hardware  of  the  final  design  that 
have  passed  the  in-process  production  screens. 

4.2.2.1.3.1.1  Components  for  STS  Usage.  For  STS  usage,  it 
should  be  demonstrated  that  the  component  can  operate  in  an  explo¬ 
sive  atmosphere.  The  component  should  not  create  an  explosion  in  an 
explosive  atmosphere;  it  should  contain  any  explosion  occurring  inside 
the  component;  and  the  temperature  of  the  component  case  and  of  all 
internal  parts  exposed  to  the  atmosphere  shall  not  exceed  178  de¬ 
grees  C.  Upon  completion  of  the  qualification  test  program,  the  quali¬ 
fication  article  may  be  used  as  a  development  test  article  for  extended 
margin  evaluation  tests  and  life  tests.  However,  the  qualification 
article  test  history  may  be  reviewed  for  excessive  test  time  and  po¬ 
tential  fatigue-type  failures  to  determine  if  the  unit  can  be  refurb¬ 
ished  and  used  in  the  qualification  vehicle  or  experiment  or  as  a  flight 
spare  in  a  redun-dant  flight  set,  but  it  should  not  otherwise  be  plan¬ 
ned  for  flight. 


4.2.2. 1.3.1.2  Reusable  Flight  Hardware  Tests.  Some  equip¬ 
ment,  or  portions  of  the  equipment,  may  be  intended  for  reuse  on 
subsequent  missions.  Reusable  equipment  would  be  subjected  to 
repeated  exposure  to  test,  launch,  flight,  and  recovery  environments 
throughout  its  life.  Qualification  testing  of  reusable  hardware  shall  be 
conducted  at  environmental  levels  and  durations  that  provide  a  suffi¬ 
ciently  high  margin  to  assure  equipment  integrity  after  the  required 
repeated  environmental  exposures.  Methodology  for  avoiding  fatigue 
failures  is  presented  in  MIL-HDBK-340. 

4.2.2.1.3.1.3  Reaualification  of  Existing  Designs.  Requali- 
Hcation  is  required  for  items  that  incorporate  extensive  changes  in 
design,  manufacturing  processing,  environmental  levels,  or  perform¬ 
ance  requirements.  However,  methodology  presented  in  MIL-HDBK- 
340  may  be  used  to  show  that  existing  designs,  or  items  previously 
qualified  for  other  applications,  have  adequately  demonstrated 
compliance  to  all  qualification  requirements  for  the  new  designs. 
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Deficiencies  in  meeting  some  requirements  may  be  fulfilled  by 
supplementing  existing  data  with  new  test  data.  However,  qualifi¬ 
cation  by  similarity  shall  be  permitted  only  with  the  concurrence  of 
the  contracting  officer.  Waiver  of  qualification  or  requalification 
requirements  requires  the  approval  of  the  contracting  officer. 

4.2.2.1.3.2  Space  Vehicle  Level  Qualification  Tests.  Quali¬ 
fication  tests  shall  be  performed  to  demonstrate,  to  the  extent  it  is 
practicable,  that  space  vehicles  that  are  manufactured  in  accordance 
with  the  approved  processes  and  controls  meet  the  specified  design 
requirements.  Except  as  specified  herein,  the  first  vehicle  manufac¬ 
tured  shall  be  acceptance  tested  and  then  qualification  tested  in 
accordance  with  the  vehicle  level  tests  in  MlL-STD-1540.  The  6-dB, 
10-degree  C,  or  other  design  factors  of  safety  or  margins  that  are 
included  in  the  design  requirements  specified  herein  include  test 
condition  tolerances  that  are  those  allowed  in  MIL-STD-1540.  When 
the  actual  test  tolerances  are  less  than  those  specified  in  MIL-STD- 
1540,  the  qualification  test  levels  may  be  reduced  appropriately  in 
accordance  with  provisions  specified  in  MIL-STD-1540.  All  qualifi¬ 
cation  tests  shall  be  conducted  with  hardware  of  the  final  design  that 
have  passed  the  in-process  production  screens. 

4.2.2.L4  Acceptance  Tests.  Acceptance  tests  shall  be  per¬ 
formed  as  the  basis  for  acceptance  of  items  manufacturea.  Acceptance 
tests,  including  lot  certification  testing,  is  that  testing  performed  to 
demonstrate  confidence  that  production  devices  that  have  passed  the 
in-process  production  screening  also  meet  the  other  requirements 
specified. 

4.2.2.1.4.1  Component  Level  Acceptance  Tests.  Except  as 
specified  herein,  space  components  shall  be  acceptance  tested  in 
accordance  with  the  component  level  tests  in  MIL-STD-1540.  For 
space  components  that  cannot  be  tested  adequately  after  assembly 
and  must  rely  upon  the  process  controls  and  in-process  production 
screening  to  assure  satisfactory  performance  and  reliability, 
appropriate  lot  cenification  tests  shall  be  imposed.  (TBS) 

4.2.2. 1.4.2  Lot  Certification  Tgst.s.  Space  parts,  materials,  and 
components  that  cannot  be  tested  adequately  after  assembly,  and 
must  rely  upon  the  process  controls  and  in-process  screening  to  assure 
satisfactory  performance  and  reliability,  shall  have  appropriate  lot 
certification  tests  imposed  prior  to  assembly.  Lot  cenification  testing 
is  that  testing  performed  to  demonstrate  confidence  that  a  lot  of  pans, 
materials,  or  components  that  have  passed  the  in-process  screening 
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also  meets  the  other  quality  and  performance  requirements.  All  items 
submitted  for  lot  certification  shall  have  been  manufactured  using  the 
same  supplier-documented  processes  and  controls.  Certification  of  a 
lot  is  achieved  by  the  satisfactory  completion  without  failure  of  the 
applicable  tests.  Note  that  lot  certification  testing  should  be  per¬ 
formed  by  the  item  supplier  and  need  not  be  repeated  by  the  user. 

4.2.2. 1.4.3  Space  Vehicle  Level  Acceptance  Tests.  Except 

as  specified  herein,  space  vehicle  acceptance  testing  shall  be  in 
accordance  with  the  vehicle  level  tests  in  MlL-STD-1540.  (TBS) 


4.2.2.1.5  Space  Vehicle  Service  Life  Verification  Tests. 
Service  life  verification  tests  are  defined  as  those  tests  conducted  on 
limited  life  devices  to  demonstrate  that  production  devices  will 
perform  satisfactorily  during  their  specified  service  life.  Explosive 
ordnance  devices  and  other  components  whose  performance  may 
degrade  with  time  shall  have  life  extensions  based  upon  passing  either 
an  aging  surveillance  test  or  an  accelerated  aging  test. 

4.2.2. 1.5.1  Aging  Surveillance  Tests.  (TBS) 

4.2.2. 1.5.2  Accelerated  Aaing  Tests.  (TBS) 

4.2.2.2  Inspections  and  Tests  of  Ground  Equipment  and 
Computer  Software.  Functional  testing  of  ground  equipment  CIs 
and  major  components  shall  be  conducted  to  demonstrate  compliance 
with  the  specified  requirements. 


4.2.2.2.1  Part.  Material,  and  Software  Unit  Development 
Tests  and  Evaluations.  Part,  material,  and  software  unit  develop¬ 
ment  tests  and  evaluations  shall  be  conducted  as  required  to  demon¬ 
strate  design  feasibility  and  to  assess  the  design  and  manufacturing 
alternatives  and  tradeoffs  to  best  achieve  the  development  objectives. 
Development  tests  may  be  required  to  validate  hardware  and  com¬ 
puter  program  design  concepts  or  to  assist  in  the  evolution  of  designs 
from  the  conceptual  phase  to  the  operational  phase.  An  objective  of 
these  tests  shall  be  to  identify  hardware  and  computer  program 
problems  early  in  their  design  evolution  so  that  any  required  correc¬ 
tive  actions  can  be  taken  prior  to  the  stan  of  formal  step  testing. 
Development  tests  may  be  used  to  confirm  performance  margins, 
manufacturability,  testability,  maintainability,  reliability,  life  expec¬ 
tancy,  and  compatibility  with  system  safety.  Where  practicable. 
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development  tests  should  be  conducted  over  a  range  of  operating 
conditions  that  exceed  the  design  limits  in  order  to  identify  marginal 
design  features. 

Internal  contractor  documentation  of  development  test  plans,  test 
procedures,  and  test  results  normally  are  used  unless  stated  otherwise 
by  a  contract. 

4.2.2.2.1.1  Part  and  Material  Level  Development  Tests 
and  Evaluations.  Part  and  material  development  tests  and  evalu¬ 
ations  shall  be  conducted  as  required  to  qualify  parts,  materials,  and 
processes  to  assure  proper  application  in  the  design,  to  assure  adeq¬ 
uate  performance  margins,  and  to  develop  acceptance  criteria  for  the 
items  to  avoid  assembling  defective  hardware  components.  The  mini¬ 
mum  required  development  tests  and  evaluations  include  qualification 
of  new  types  of  parts,  materials,  and  processes  to  assure  proper  appli¬ 
cation  in  the  design,  and  to  develop  acceptance  criteria  for  the  items  to 
avoid  assembling  defective  hardware  components.  For  each  part  or 
material  tested  or  evaluated,  the  test  procedures,  test  results,  and 
deficiencies  or  problems  encountered  and  resolutions  shall  be  docu¬ 
mented  in  an  informal  hardware  development  file  (HDF)  maintained 
by  the  development  contractor.  The  intent  is  to  make  the  HDF  the 
source  for  design  data  for  the  parts  and  materials  used. 

4.2.2.2.1.2  Subassembly  Level  Development  Tests  and  In. 
process  Tests  and  Inspections.  Subassemblies  shall  be  subjected 
to  development  tests  and  evaluations  as  may  be  required  to  demon¬ 
strate  feasibility,  to  minimize  design  risk,  and  to  assess  the  design  and 
manufacturing  alternatives  and  tradeoffs  required  to  best  achieve  the 
development  objectives.  Tests  shall  be  conducted  as  required  to 
develop  in-process  manufacturing  tests,  inspections,  and  acceptance 
criteria  for  the  items  to  avoid  assembling  defective  hardware  items. 

4.2.2.2.1.3  Computer  Software  Unit  Tests.  The  earliest 
development  tests  and  evaluations  of  software  are  performed  on 
computer  software  units  (CSUs)  which  are  the  smallest  software 
element  of  a  computer  software  component  that  is  separately  testable. 
As  a  minimum,  each  CSU  shall  be  tested  to  ensure  that  the  algorithms 
and  logic  employed  are  correct  and  that  the  CSU  satisfies  its  specified 
requirements.  For  each  CSU  or  logically  related  group  of  CSUs,  the  test 
procedures,  design  code,  test  results,  and  deficiencies  or  problems 
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encountered  and  resolutions  shall  be  documented  in  a  software  devel¬ 
opment  file  (SDF)  maintained  by  the  development  contractor.  When¬ 
ever  the  design  or  coding  are  changed,  the  CSU  shall  be  retested,  as 
necessary,  and  all  documentation  pertinent  to  the  changes  shall  be 
revised  and  updated. 

4.2.2.2.2  Step  1:  Component  Tests  and  Evaluation 
(Development) 

4.2.2.2.2.1  Step  1:  Hardware  Components.  Hardware  com¬ 
ponents  shall  be  subjected  to  tests  and  evaluations  as  may  be  required 
to  qualify  the  components  to  assure  proper  application  in  the  design, 
to  assure  adequate  performance  margins,  and  to  develop  acceptance 
criteria  for  the  components  to  avoid  assembling  defective  hardware. 
Component  tests  and  evaluations  also  may  be  required  to  demonstrate 
manufacturing  feasibility  and  to  assess  the  design  and  manufacturing 
alternatives  and  tradeoffs  required  to  best  achieve  the  development 
objectives. 


4.2.2.2.2.2  Step  1:  Software  Components.  The  CSUs  forming 
a  software  component  with  specific  functions  constitute  a  CSC.  The  CSC 
tests  shall  be  conducted  to  assure  that  all  algorithms  and  logic  used  in 
each  CSC  are  correct  and  satisfy  their  allocated  requirements.  The 
tests  also  shall  evaluate  any  design  alternatives  or  tradeoffs,  demon¬ 
strate  the  feasibility  of  the  CSC  design,  and  assure  that  design  risks  are 
minimized. 

4.2.2.2.3  Step  2:  Configuration  Item  Compliance  Tests 
(Qualification  and  Acceptance).  Step  2  tests  are  the  qualification 
and  acceptance  tests  of  a  Cl,  either  a  hardware  configuration  item 
(HWCI),  a  CSCI,  or  a  Cl  consisting  of  both  hardware  and  software.  The 
Step  2  tests  include  qualification  and  acceptance  tests  of  combined  CIs. 
All  Step  2  tests  shall  be  conducted  using  prequalified  test  tools  and 
test  procedures  designed  to  attain  the  test  objectives  in  the  approved 
test  plans.  When  included  within  the  scope  of  the  contract,  the  com¬ 
pletion  of  these  tests  may  be  made  contingent  on  the  satisfactory 
completion  of  subsequent  integrated  system  tests.  A  Functional 
Configuration  Audit  and  a  Physical  Configuration  Audit  normally  are 
conducted  in  accordance  with  contract  requirements  following  the 
completion  of  Step  2.2  tests. 
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4.2.2.2.3.1  Step  2.1:  Single  Cl  Compliance  Tests 

4.2.2.2.3.1.1  Step  2.1:  Hardware  Cl  Oualincation.  Each 

HWCI  type  shall  be  formally  qualified.  The  qualification  tests  shall 
verify  that  the  Cl  meets  the  specified  system  design  requirements 
allocated  to  the  Cl,  including  external  interfaces.  The  qualification 
tests  shall  verify  the  performance  margins  by  evaluating  the  func¬ 
tional  performance  of  the  Cl  in  an  environment  that  simulates  the 
operational  environments  associated  with  the  Cl. 

4.2.2.2.3.1.2  Step  2.1:  Hardware  CT  Acceptance.  The 

qualification  tests  on  the  first  production  item  of  each  type  serve  as 

the  acceptance  test  for  that  item.  Subsequent  production  items  of 
each  type  shall  be  formally  acceptance  tested  as  required.  The 
acceptance  tests  of  the  subsequent  production  items  may  be  a  subset 
of  the  qualification  tests. 

4.2.2.2.3.1.3  Step  2.1:  Computer  Software  Cl  Qualification. 

Functional  or  logically  distinct  CSCs  are  organized  or  grouped  into 
CSCIs.  Each  CSCI  performs  or  executes  a  set  of  functions  or  tasks. 
Formal  qualification  tests  shall  be  conducted  on  each  CSCI  to  verify 
CSCI  compliance  with  design  or  specified  requirements,  i.e.,  stressing 
the  CSCIs  to  the  limits  of  their  specified  requirements.  Step  2.1  tests 
associated  with  software  maintenance  shall  be  conducted  on  the  CSCI 
as  required  to  verify  that  the  deficiency  documented  in  the  problem 
aescription  has  been  corrected. 

4.2.2.2.3.2  Step  2.2;  Combined  Cl  Compliance  Tests.  A 
series  of  compliance  test  Steps  shall  be  conducted  on  expanding 
strings  of  CIs.  Typically,  a  HWCI  is  combined  with  other  HWCIs  and 
the  combination  tested,  a  CSCI  is  combined  with  other  CSCIs  and  the 
combination  tested,  and  then  the  various  CIs  are  combined  until  the 
final  end  item  ground  equipment  to  be  delivered,  including  the  inter¬ 
faces.  The  actual  combination  of  CIs  to  be  tested,  and  the  particular 
test  sequence  to  follow,  depend  on  the  complexity  of  the  development, 
criticality  of  the  functions,  and  on  the  external  interfaces  involved. 

The  tests  shall  be  designed  to  confirm  functional  compatibility  among 
the  mechanical,  electrical,  and  computer  software  interfaces.  Step  2.2 
tests  shall  demonstrate  that  the  end  item  functions  resulting  at  each 
test  sequence  of  combined  CIs  meet  the  performance  requirements 
and  system  specifications.  To  show  the  planned  sequence  for  the  Step 

2.2  tests,  the  detailed  tests  should  be  identified  further  as  Step  2.2.1 
tests.  Step  2.2.2  tests.  Step  2.2.3  tests.  Step  2.2.4  tests,  and  so  forth  for 
the  expanding  strings  of  configuration  items. 
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4.2.2.2.3.3  Commercial  Off-the-shelf  or  Government- 
Furnished  Equipment  Testing.  Commercial  of f-the> shelf  (COTS) 
items  that  are  not  developed  specifically  for  acquisition  or  modifi¬ 
cation  often  are  included  in  the  system  design.  Also,  GFE  may  be 
included  in  the  system  design.  The  COTS  or  GFE  items  may  be  either 
hardware,  software,  or  a  combination  of  the  two.  If  incorporated  in 
the  system  design,  the  COTS  and  GFE  testing  shall  be  included  in  the 
testing  baseline,  that  is,  as  incorporated  in  the  configuration  tested  for 
compliance.  Individual  tests  shall  be  conducted  on  COTS  and  GFE  prior 
to  incorporation  in  the  configuration  or  assembly,  as  specified  in  the 
applicable  acquisition  contract.  The  test  shall  be  conducted  at  the 
level  of  detail  necessary  to  determine  whether  the  COTS  and  GFE 
perform  satisfactorily,  are  documented  adequately  for  the  application, 
and  satisfy  the  system  requirements  allocated  to  them. 

4.2.2.2.3.4  Computer  Resources  Reserves  Verification.  The 
space  system  computer  resources  reserves  specified  in  Paragraph 
3.2.8,  and  its  subparagraphs,  shall  be  verified  through  incremental 
testing,  the  final  increment  being  conducted  as  part  of  the  system- 
level  testing  for  the  particular  element  of  the  space  system  involved 
[e.g.,  operational  (ground),  operational  (space),  maintenance,  test, 
trainers,  etc.].  The  tests  shall  be  conducted  to  demonstrate  that  the 
worst  case  throughput  requirements  specified  in  government- 
approved  load  scenarios  have  been  met.  At  least  four  incremental 
tests  shall  be  conducted  per  identified  system  element  or  subsystem: 

a.  Isolated  subsystem/first  software  version 

b.  Isolated  subsystem/last  pre-baseline  software  version 

c.  Combined  subsystems/last  pre-baseline  software  versions, 
(optional  as  required) 

d.  Baselined  full  element  or  subsystem 

Each  test  increment  shall  establish  that  the  throughput  reserve 
remains  available  under  the  worst  case  space  system  test  scenarios. 

4.2.2.2.4  Step  3:  Integrated  System  Testing.  Integrated 
system  tests  shall  be  designed  to  exercise,  as  near  as  practical  and 
possible,  the  total  system.  The  intent  is  to  ensure  that  the  products, 
which  may  be  from  multiple  contractors,  arc  integrated,  that  inter¬ 
faces  are  verified,  and  that  all  higher-level  operational  requirements 
or  specifications  arc  met.  Where  practicable,  integrated  system  tests 
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shall  be  performed  on  integrated  CIs  installed  in  an  operational 
system.  Whenever  possible,  these  tests  shall  be  conducted  at  the 
target  site  with  the  support  of  the  operational  personnel.  A  develop¬ 
ment  test  bed  approved  by  the  Acquisition  Activity  as  sufficiently 
simulating  the  operational  system  capability  for  test  purposes  may  be 
used  for  Step  3  integrated  system  tests  if  target  sites,  operational 
complexes,  or  other  suitable  operational  support  areas  are  not  avail¬ 
able.  The  Step  3  integrated  system  tests  shall  incorporate  tests  of  the 
affected  interfaces  of  the  ground  equipment  and  software  with  other 
elements  of  the  operational  system.  The  Step  3  tests  shall  be  struc¬ 
tured  as  appropriate  to  demonstrate  design  requirements  of  the 
system  related  to  such  items  as  performance,  electromagnetic  com¬ 
patibility,  reliability,  maintainability,  system  safety  (hazardous  noise, 
radiation  hazards,  pressure  vessels),  logistics  supportability,  opera¬ 
tional  procedures,  and  personnel  performance. 

Step  3  tests  shall  be  conducted  to  demonstrate,  as  applicable  to  the 
system  design  (or  modification),  that: 

a.  Reliable  operation  is  achieved  at  specified  design  limits. 

b.  Specified  system  functional  and  performance  requirements 
are  met. 

c.  The  system  can  recover  from  hardware  or  software 
malfunctions  within  a  reasonable  or  specified  time  without 
loss  of  data  or  control. 

d.  Performance  requirements  are  met  under  all  required  logical 
or  physical  device  assignment  combinations. 

e.  The  software  and  hardware  modifications  or  upgrades  have 
not  degraded  the  capability  of  the  system's  baseline  or  of 
other  operational  systems,  unless  specifically  designed  to  do 
so. 

f.  Security  mechanisms  arc  in  place  or  incorporated  to  protect 
resources  from  unauthorized  access  or  break-in  from  illicit 
users. 

Tests  shall  be  focused  on  the  external  interfaces  involved,  the  use 
of  operational  databases  and  operational  scenarios,  and  the  system 
requirements  from  a  mission  operations  perspective. 
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The  Step  3  tests  also  shall  include  other  applicable  tests,  such  as 
a  reliability  demonstration;  a  maintainability  demonstration;  system 
safety  tests,  inspections,  and  evaluations  in  such  areas  as  hardware 
inspections  for  electrical  and  mechanical  hazard,  including  caution 
labeling;  evaluation  of  the  fire  suppression  system;  evaluation  of 
emergency  systems;  use  of  any  hazardous  materials;  possibility  of 
personnel  exposure  to  any  equipment  and  ambient  noise  levels 
considered  hazardous;  RF  radiation  testing  to  determine  actual  levels 
of  radiation  to  which  personnel  may  be  exposed  and  to  evaluate  the 
accuracy  of  the  mathematical  predictions  of  radiation  levels;  proper 
functioning  of  any  radiation  warning  systems;  and  proper  procedures 
for  inspection,  operation,  and  maintenance  of  pressure  vessels. 

Step  3  integrated  system  tests  shall  be  conducted  by  an  indepen¬ 
dent  test  organization  approved  by  the  acquisition  activity.  This  test 
organization  shall  be  responsible  for  the  development  of  test  plans, 
test  tools,  and  test  procedures  and  the  conduct  of  the  test.  Develop¬ 
ment  contractors  provide  support  for  the  Step  3  tests  and  the  resolu¬ 
tion  of  deficiencies  only  within  the  scope  of  the  applicable  contract 
provisions  and  as  directed  by  the  acquisition  activity. 

4.2.2.2.5  Step  4;  Initial  Operational  Test  and  Evalua¬ 
tion.  Initial  operational  tests  and  evaluations  (lOT&E)  are  conducted 
with  the  equipment  in  its  operational  configuration,  in  an  operational 
environment,  by  the  operating  personnel.  These  Step  4  tests  are 
conducted  in  an  environment  that  is  as  operationally  realistic  as 
possible  and  practical  in  order  to  test  and  evaluate  the  effectiveness 
and  suitability  of  the  hardware  and  software  in  meeting  operational 
requirements.  Step  4  tests  emphasize  reliability,  maintainability, 
supponability,  and  logistics.  Satisfactory  completion  of  the  Step  4 
tests  is  the  milestone  for  the  initial  operational  capability. 

4.2.2.2.6  Step  5:  Follow-on  Operational  Test  and  Evalua¬ 
tion.  Follow-on  operational  tests  and  evaluations  (FOT&E)  are  con¬ 
ducted  with  the  equipment  in  its  operational  location  by  the  operating 
personnel  assigned.  The  Step  5  tests  demonstrate  and  verify  the 
continued  capability  of  the  system,  with  the  modification  or  upgrade 
incorporated,  to  support  ongoing  missions.  The  FOT&E  are  conducted 
to  refine  estimates  made  during  lOT&E  and  to  identify  operational 
system  deficiencies. 
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4.2.3.1  Test  Eauipment.  Test  equipment  is  that  equipment 
required  to  support  the  maintenance,  repair,  and  checkout  of  the 
system  hardware  following  system  deployment.  To  the  extent 
practicable,  test  equipment  shall  be  designed  using  applicable 
commercial  practices.  Commercially  available  modules  shall  be  used 
to  the  extent  practicable. 

4.2.3.2  Trainers.  The  trainers  are  the  equipment  to  be  used  for 
the  training  of  system  operator  personnel.  To  the  extent  practicable, 
trainers  shall  be  designed  using  the  same  interfacing  controls, 
displays,  and  equipment  locations  as  occur  operationally.  Trainers 
shall  be  designed  using  applicable  commercial  practices. 

4.2.3.3  Comnufer  Software  Maintenance  Resojirces.  (TBD) 

4.2.4  Prelaunch  Validation  Tests.  Prelaunch  validation  tests 
of  the  first  operational  space  vehicle  usually  is  conducted  as  part  of 
the  Step  4  testing.  All  subsequent  operational  space  vehicles  shall  be 
subjected  to  prelaunch  validation  tests  to  assure  that  there  are  no  out- 
of-tolerance  conditions  or  anomalous  behavior.  To  the  extent  practic¬ 
able,  prelaunch  system-level  inspections  and  tests  shall  be  conducted 
to  verify  by  end-to-end  testing  that  each  critical  path  in  the  launch 
system,  the  on-orbit  system,  and  the  reentry  system  is  satis-factory. 
Duplication  of  the  factory  acceptance  functional  tests  in  subsequent 
tests  also  is  intended  to  provide  data  for  trend  analysis  that  might 
provide  evidence  of  a  potential  problem,  even  though  all  current 
measurements  were  within  tolerances.  Whether  electrical,  mechan¬ 
ical,  or  both,  all  critical  paths  or  circuits  shall  be  verified  from  the 
application  of  the  initiating  signal  through  completion  of  each  event. 
This  testing  is  intended  to  verify  that  an  event  command  or  signal  was 
generated  properly  and  sent  on  time,  that  it  arrived  at  its  correct 
destination,  that  no  other  function  was  performed,  and  that  the  signal 
was  not  present  other  than  when  programmed.  Once  success-fully 
accomplished,  that  particular  critical  path  or  circuit  is  considered 
validated.  Not  all  end-to-end  tests  can  be  performed  with  only  flight 
hardware,  as  in  the  case  in  which  an  explosive  event  is  involved.  In 
cases  in  which  end-to-end  testing  cannot  be  performed  with  the  flight 
hardware  and  software,  appropriate  simulation  devices  should  be 
used  to  exercise  the  flight  hardware  and  software  to  the  maximum 
extent  possible.  Simulation  devices  should  be  controlled  carefully  and 
should  be  permitted  only  when  there  is  no  feasible  alternative  for 
conducting  the  test.  All  of  the  events  that  occur  during  the  mission 
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profile  should  be  tested  in  the  flight  sequence  to  the  extent  that  is 
practical.  Redundant  components  and  subsystems  also  should  be 
validated  in  the  same  manner. 

4.2.4.1  Space  Vehicle  Prelaunch  Validation  Tests.  Pre¬ 
launch  validation  tests  shall  be  conducted  on  space  equipment  in 
accordance  with  the  applicable  requirements  of  MIL-STD-1540.  The 
space  vehicle  shall  be  operated  through  a  simulated  sequence  of 
ascent  phase,  separation  and  engine  ignition  phase,  orbital  injection, 
on-orbit  operation  and,  if  applicable,  recovery  phase.  These  inte¬ 
grated  system  tests  shall  include  all  tests  designed  to  verify  system 
performance. 


4.2.4.1.1  Functional  Integration.  End-to-end  integration  tests 
shall  be  conducted  to  assure  an  orderly  buildup  and  verify  proper 
subsystem  operation. 

4.2.4.1.2  Alignment  Checks.  Alignment  checks  shall  be 
conducted  as  required  to  verify  alignments  of  speciHc  equipment. 

4.2.4. 1.3  Integrated  System  Tests.  Integrated  system  tests 
are  system -level  functional  tests  conducted  in  accordance  with  the 
applicable  paragraphs  of  MIL-STD-1540.  Integrated  system  tests 
provide  baseline  performance  data  and  follow-up  comparison  data  to 
verify  factory  tests  and  assure  that  no  degradation  results  from  the 
individual  environmental  tests,  transportation,  storage,  and  preceding 
flights.  Integrated  system  tests  shall  include  a  "typical"  flight  simu¬ 
lation  encompassing  prelaunch,  launch,  and  orbital  modes  of  operation. 

4.2.4.1.4  Mass  Properties.  Actual  weight  and  center-of- 
gravity  (eg)  measurements  are  required  at  the  component  and  at  each 
higher  level  of  assembly  to  verify  predictions  and  to  ensure  that  the 
installed  equipment  meets  final  weight  and  eg  requirements. 

4.2.4. 1.5  High  Pressure.  Tests  of  all  pressure  subsystems  of 
the  integrated  equipment  shall  be  performed  in  accordance  with  MIL- 
STD-1540  (Paragraph  6.2.6),  NHB  1700.7  (NASA),  and  SAMTO  HB  S- 
100  (designated  by  NASA  as  KHB  1700.7). 

4.2.4.2  Launch  System  Prelaunch  Validation  Tests.  Pre¬ 
launch  validation  tests  shall  be  conducted  on  the  launch  vehicle  in 
accordance  with  the  applicable  requirements.  These  integrated 
system  tests  include  all  tests  designed  to  verify  system  and  launch 
conductor  performance.  (TBD) 


A-103 


SPEC  NUMBER  SS-01  APPENDIX  A 

15  OCT  91 

4.2.4.3  On-orbit  System  Prclaunch  Validation  Tests. 
Prelaunch  validation  tests  shall  be  conducted  on  the  on-orbit 
system  in  accordance  with  the  applicable  requirements.  These 
integrated  system  tests  include  all  tests  designed  to  verify  system  and 
operator  performance.  (TBD) 

4.2.4.4  Certification  for  Flight.  Upon  completion  of  the  inte¬ 
grated  system  tests,  the  test  history  of  the  integrated  equipment  shall 
be  reviewed  to  determine  its  acceptability  for  flight.  The  concept  of 
product  flight  accreditation  is  used  to  assure  that  the  critical  com¬ 
ponents  satisfy  all  requirements  that  have  been  found  necessary  for 
successful  space  missions.  Note  that  items  furnished  by  other  GFE 
may  require  additional  testing  or  controls  to  satisfy  the  flight  accredi¬ 
tation  requirements.  Flight  accreditation  is  a  process  in  which  the 
status  of  each  item  is  under  continuing  evaluation  from  program 
inception  to  final  accreditation  for  flight.  The  extent  of  reviews 
required  is  dependent  upon  the  specific  qualification  and  production 
status  of  the  experiment  to  be  flown  and  the  suitability  of  its  as- 
qualified  design  for  the  intended  mission  application.  Unless  specifi¬ 
cally  excluded,  flight  accreditation  should  incorporate  all  technical 
assessment  activity  from  inception  of  the  program  through  manufac¬ 
turing,  qualification,  transportation,  handling,  storage,  and  post- 
delivery  operations  leading  to  final  installation  and  checkout  prior  to 
flight.  The  assessment  activity  involves  incremental  reviews  and 
culminates  in  documentation  that  all  accreditation  requirements  have 
been  met.  After  completion  of  the  final  review  for  each  item,  the 
acceptability  or  nonacceptability  for  flight  is  documented. 

Items  are  considered  to  be  flight  accredited  if  the  items  satisfy  all 
of  the  following  conditions  or  the  conditions  have  been  waived  by  the 
contracting  officer: 

a.  The  items  have  passed  the  specified  design  verification  tests. 

b.  The  items  have  passed  the  qualiHcation  or  protoflight  test 
requirements. 

c.  The  items  that  require  lot  certification  are  from  a  lot  that 
passed  the  specified  lot  certification  tests.  Government- 
furnished  items  are  not  exempt  from  this  requirement.  If 
prior  lot  certification  testing  has  not  met  the  requirements 
contained  herein,  testing  should  be  conducted  to 
demonstrate  compliance. 
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d.  The  items  have  been  transported  and  stored  within  the 
specified  environmental  limits  for  the  device. 

e.  The  items  are  from  a  lot  that  has  an  adequate  service  life  for 
the  scheduled  operational  use. 

4.3  REQUIREMENTS  CROSS  REFERENCE 

For  guidance  in  correlating  the  Section  4  requirements  with  the 
Section  3  and  Section  5  requirements,  and  tor  use  in  developing  test 
plans,  a  requirements  cross  reference  matrix  is  provided  in  Appendix 
C  (or  Document  456X).  (Note  that  if  a  separate  Document  456X  is  used 
instead  of  Appendix  C,  Document  4S6X  is  added  to  the  list  of  refer¬ 
ences  in  Section  2.  If  the  contractor  is  required  to  prepare  or  update 
the  matrix,  that  requirement  must  be  listed  in  the  CDRL. 
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SECTION  5 

PREPARATION  FOR  DELIVERY 


(Not  applicable) 
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SECTION  6 
NOTES 


6.1  INTENDED  USE 

The  space  system  covered  by  this  specification  is  intended  for  use 
in  the  (insert  nomenclature)  space  program.  (TBS) 

6.1.1  Missions.  (See  3. 1.4.3) 

6.1.2  Threat.  (See  3.1. 4.4) 

6.2  ORDERING  DATA 

6.2.1  Precedence  Requirements.  For  precedence  require¬ 
ments,  see  Subsection  3.8. 

6.2.2  Trade  Studies.  If  there  are  particular  trade  studies  that 
are  critical  to  the  development  process,  they  should  be  specifically 
identified  and  required  by  the  SOW.  In  addition,  the  system  life  cycle 
cost  model  to  be  used  for  trade  studies  of  various  alternatives  may  be 
critical  to  the  acquisition  process,  particularly  in  the  early  phases.  For 
that  reason,  the  model  may  be  GFE  or  it  may  require  government 
approval.  If  the  system  life  cycle  cost  model  is  developed  by  the  con- 
tractor(s),  the  government  may  want  to  require  delivery  in  a  usable 
form  to  assure  its  availability  for  subsequent  phases  or  for  use  by 
other  contractors. 

6.2.3  Technical  Review.  The  government  plans  for  conducting 
technical  reviews  and  audits  should  be  clearly  stated  in  the  contract. 

In  particular,  the  use  of  weighting  factors  in  the  specification  is  in¬ 
tended  to  help  identify  design  review  items  that  should  be  addressed 
in  the  contract  SOW  or  in  the  Program  Management  Plan.  For  exam¬ 
ple,  if  the  contractor  docs  not  follow  a  "preferred”  requirement,  what 
level  of  justification,  if  any,  is  expected  at  a  design  review?  If  the 
contractor's  design  docs  comply  with  a  "preferred"  requirement, 
would  a  justification  of  that  decision  be  required  at  the  design  review? 

6.2.4  Data  Items.  The  requirements  for  the  delivery  of  data 
items  believed  critical  to  understanding  the  acquisition  status  should 
be  clearly  stated  in  the  CDRL.  Usually  the  contract  will  include  a  line 
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item  to  provide  for  the  delivery,  on  request,  of  any  internally 
generated  contractor  document  listed  on  the  data  accession  list. 


6.3  DEFINITIONS 

(TBS) 

6.4  ABBREVIATIONS  AND  ACRONYMS 

(TBS) 


r^IITDANrE  noniMENTS 


The  following  documents  provide  information  and  data  that  may 
be  useful  in  the  allocation  of  the  stated  requirements  to  lower  levels 
of  assembly  or  in  the  preparation  of  more  detailed  documentation 
required  by  the  acquisition  process: 

(TBS) 


(Copies  of  these  publications  may  be  obtained  from  the  contracting 
office  or  as  directed  by  the  contracting  officer.) 


6.6  TAILORED  APPLICATIONS 

It  is  intended  that  the  requirements  in  documents  referenced  in 
this  specification  arc  referenced  in  ways  that  properly  tailor  the 
requirement  for  each  application.  Nevertheless,  all  requirements  of 
this  specification,  including  referenced  requirements,  should  be 
evaluated  for  each  application,  and  those  that  are  inappropriate,  or 
that  seem  to  increase  system  life  cycle  cost,  should  be  identified  and 
reviewed.  The  stated  order  of  precedence  of  requirements,  including 
the  use  of  the  weighting  factors  in  the  specification,  is  intended  to 
assist  contractors  in  the  design  process,  trade  studies,  and  in  the 
allocation  of  requirements  to  specific  applications.  Contractors  are 
encouraged  to  identify  to  the  contracting  officer,  for  program  office 
review  and  consideration,  any  requirements  imposed  by  this 
specification  that  are  believed  excessive  or  conflicting.  However, 
contractors  are  reminded  that  deviations  from  contractually  imposed 
requirements  can  be  granted  only  by  the  contracting  officer. 
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6.7  REVISION  MARKING 

Symbols  are  not  used  in  this  revision  to  identify  changes  with 
respect  to  the  previous  issue,  due  to  the  extensiveness  of  the  changes. 

[Note  that  if  the  changes  are  not  extensive,  the  following  statement 
may  be  used  in  Subsection  6.6  instead; 

The  margins  of  this  specification  are  marked  with  a  vertical  bar  (or 
symbol)  to  indicate  where  changes  (additions,  modifications,  corrections,  deletions) 
from  the  previous  issue  were  made.  This  was  done  as  a  convenience  only,  and  the 
government  assumes  no  liability  whatsoever  for  any  inaccuracies  in  these 
notations.  Bidders  and  contractors  are  cautioned  to  evaluate  the  requirements  of 
this  document  based  on  the  entire  content  irrespective  of  the  marginal  notation  and 
relationship  to  the  last  previous  issue. 

Note  that  if  the  specification  is  the  initial  issue,  this  subparagraph 
would  not  be  included.] 
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10.  THREAT  ENVIRONMENT 


This  appendix  is  a  mandatory  pan  of  the  specification. 


10.1  5.0)  PE 

This  appendix  sets  forth  the  threat  environment  for  the  (insert 
nomenclature)  system. 

10.2  APPLICABLE  DOCUMENTS 
(TBS) 

lOJ  REQUIREMENTS 

10.3.1  Ground  Tracking  Stations.  Perimeter  fences  around 
ground  tracking  stations  that  are  located  in  tropical  areas  may  be 
attacked  by  (TBS). 

10.3.2  Space  Vehicles.  (TBS) 

10.3.3  (TBS) 
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APPENDIX  B 

20.  REQUIREMENTS  TRACEABILITY  MATRIX 


This  appendix  is  not  a  mandatory  pan  of  the  specification. 


20.1  S£I1£E 

This  appendix  outlines  a  Requirements  Traceability  Matrix  for  the 
correlation  of  the  Section  3  requirements  with  each  hardware  Cl  and 
each  software  CL 

20.2  APPLICABLE  DOCUMENTS 
(Not  applicable) 

20J  REQUIREMENTS 

The  correlation  of  each  hardware  Cl  and  each  software  Cl  with  the 
Section  3  requirements  is  shown  in  Table  B-I. 


Table  B-I.  Requirements  Traceability  Matrix. 


SECTION  3 

REQUIREMENT  REQUIREMENT 

HARDWARE 

HARDWARE 

PARAGRAPH 

[  NAME  NUMBER 

Cla  ...  CIz 

Cla  ...  Clz 

1 

3.2.5. 1 

Reliability  a 

58 

X ...  X..- 

-X...-X 

3.2.5.1 

Reliability  b 

59 

X ...  X..- 

-X...-X 

3.2.5.1 

Reliability  c 

60 

X ...  X..- 

-X...-X 

3.3.12.9 

Wiring  Harness  a 

113 

XXXXX  - 

2.2.12.9 

Wiring  Harness  b 

114 

XXXXX  - 
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APPENDIX  C 

30.  REQUIREMENTS  CROSS  REFERENCE  MATRIX 


This  appendix  is  not  a  mandatory  part  of  the  specification. 


30.1  SCOPE 

This  appendix  outlines  a  requirements  cross-reference  matrix  for 
the  correlation  of  the  Section  3  requirements  with  the  Section  4 
quality  assurance  provisions. 

30.2  APPLICABLE  DOCUMENTS 

(Not  applicable) 

303  REQUIREMENTS 

The  correlation  of  the  Section  4  quality  assurance  provisions  with 
the  Section  3  requirements  is  shown  in  Table  C-I.  The  verification 
methods  are  described  in  the  following  paragraphs. 

30.3.1  Inspection.  Inspection  may  be  used  for  the  visual 
determination  of  an  item's  qualitative  or  quantitative  properties  such 
as  tolerances,  finishes,  and  identiHcation. 

30.3.2  Analysis.  Analysis  may  be  used  for  determination  of 
qualitative  and  quantitative  properties  and  performance  of  an  item  by 
study  calculations  and  modeling.  Similarity  analysis  may  be  used  in 
lieu  of  tests  when  it  can  be  shown  that  an  item  is  similar  or  identical 
in  design  to  another  item  that  has  been  certified  previously  to  equiva¬ 
lent  or  more  stringent  criteria. 

30.3.3  Demonstration.  Demonstration  may  be  used  for  deter¬ 
mination  of  qualitative  and  quantitative  properties  and  performance 
of  an  item  and  is  accomplished  by  example.  Verification  of  an  item  by 
this  method  would  be  by  using  it  for  its  designed  purpose  and  would 
require  no  special  test  for  final  proof  of  performance. 
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30.3.4  Test.  Tests  may  be  used  for  the  determination  of 
qualitative  and  quantitative  properties  and  performance  of  an  item  by 
technical  means,  which  requires  the  use  of  external  resources  such  as 
volt  meters,  recorders,  and  any  test  equipment  necessary  for 
measuring  performance. 
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Table  C-I. 


Requirements  Cross  Reference  Matrix. 


SECnON 

REQUIRE¬ 

REQUIRE¬ 

VERIFI¬ 

ASSEM¬ 

SECTION 

3 

MENT 

MENT 

CATION 

BLY 

4 

PARA¬ 

NAME 

NUMBER 

meihodi 

LEVEL2 

TEST 

GRAPH 

PARA- 

Reliability  a 

58 

A 

1 

4.2.2. 1 

3. 2.5  A 

Reliability  b 

59 

T 

2 

4.2.2.2 

3.2.5.1 

Reliability  c 

60 

T 

3 

4.2.2.3 

3.3.12.9 

Wiring 

Harness  a 

113 

T 

2 

4.2.2.3 

3.3.12.9 

Wiring 

Harness  b 

114 

T 

3 

4.2.2.4 

3.8.1 

... 

_ N/A _ 

. 

^VERm 

CATION  METHOD 

2level  of  assembly 

A 

-  ANALYSIS 

1  -  PART  OR  MATERIAL 

D 

-  DEMONSTRATION 

2  -  COMPONENT 

I 

-  INSPECTION 

3  -  VEHICLE  LEVEL 

T 

-  TEST 

4  -  SYSTEM  LEVEL 

N/A 

-  NOT  APPLICABLE 

TEST  CATEGORY  LEGEND: 

A  -  Design  Verification  Test 

B  •  Qualification  Test 

C  -  Acceptance  Test 

D  -  Service  Life  Verification  Test 

E  -  Prelaunch  Validation  Test 
F  -  Operational  Test 

G  -  Step  1:  Component  Tests  and  Evaluation  (Development) 

H  -  Step  2:  CI/CSCI  Compliance  Tests  (Qualification  and 
Acceptance) 

I  -  Step  2.1:  Single  Cl  OR  CSCl  Compliance  Tests 

J  -  Step  2.2:  Combined  CI/CSCI  Compliance  Tests 

K  -  Step  2.3:  Combined  CI/CSCI  Compliance  Tests 

L  -  Step  2.4:  Combined  CI/CSCI  Compliance  Tests 

M  -  Step  3:  Integrated  System  Testing 
N  -  Step  3.1:  Preliminary  Integrated  System  Tests 
O  -  Step  3.2:  Final  Development  Test  and  Evaluation  (FDT&E) 
P  -  Step  4:  Initial  Operational  Test  and  Evaluation  (lOTE) 

Q  -  Step  5:  Follow-on  Operational  Test  and  Evaluation 
(FOT&E) 
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DATA  ITEM  DESCRIPTION 

form  AOO^O^et 

0MB  No.  070A^^oa 

1.  TITLE 

SYSTEM/SEGMENT  SPECIFICATION 

1.  IDENTIFICATION  NU.MBER 

DI-CMAN-80008A 

3.  OeSCHlPTlON/PORPOSE 

3.1  The  System/Segment  Specification  (SSS)  specifies  the  requirements  for  a  system  or  a  segment  of  a 
system.  Upon  Government  approval  and  authentication,  the  SSS  becomes  the  Functional  Base  me  for  the 
system  or  segment. 

(continued  on  page  2) 


4.  approval  date 
(YYMMOOl 

880229 


S.  OFPICE  OF  PRIMARY  RESPONSIBILITY  (OPRI 

AF-10 


[  Sa.  OTIC  APPLICABLE  6b.  GlOE?  APPLICABL 


7.  APPLICATION/INTERRELATIONSHIP 

7.1  This  Data  Item  Desc.'iption  (DID)  contains  the  format  and  content  preparation  instructions  for  data 
generated  under  the  work  tasks  described  by  paragraph  3. 1.3.1  of  MIL-STD-490. 

7.2  The  Contract  Data  Requirements  List  should  specify  whether  this  document  is  to  be  prepared  and 
delivered  on  bound  8  1/2  by  11  inch  bond  paper  or  electronic  media.  If  electronic  media  is  selected,  the 
precise  format  must  be  specified. 

(continued  on  page  2) 


M.  oisraiBUTicN  staTc-ment 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release:  distribution  is  unlimited. 


OO  Form  1664.  JUN  SB 


^evfous  Minting  grw 
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D1-CMAN-80008A 

3.  DESCRIPTION/PURPOSE  (continued) 

3.2  The  SSS  provides  a  general  overview  of  the  system  or  segment  that  may  be  used  by  training 
personnel,  support  personnel,  or  users  of  the  system. 


7.  APPLICATION/INTERRELATIONSHIP  (continued) 

7.3  The  word  ’system"  is  used  genetically  in  this  DID  to  mean  either  a  system  or  a  segment,  as 
applicable. 

7.4  System  division  into  segments  normally  occurs  if  parts  of  the  system  are: 

a.  Assigned  to  different  contractors  or  government  organizations 

b.  Intended  to  be  added  in  an  evorutionary  or  incremental  manner 

c.  Planned  for  major  modification. 

7.5  This  DID  supersedes  DI-ChtAN-a0008  dated  4  June  1985. 


10.  PREPARATION  INSTRUCTIONS  (continued) 

d-  Document  control  numbers.  For  hardcopy  formats,  this  document  may  be  printed  on  one  or 
both  sides  of  each  page  (single-sided  or  double-sided).  All  printed  pages  shall  contain  the 
document  control  number  and  the  date  of  the  document  centered  at  the  top  of  the  page. 
Document  control  numbers  shall  include  revision  and  volume  identification,  as  applicable. 

Multiple  (subioaraQraphs.  All  paragraphs  and  subparagraphs  starting  with  the  phrase  This 
(sub)paragraph  shall..."  may  be  written  as  multiple  subparagraphs  to  enhance  readability.  These 
subparagraphs  shall  be  numbered  sequentially. 

f.  Identifiers.  The  letters  *X",  "Y",  and  *Z"  serve  as  identifiers  for  a  series  of  descriptions.  For 
example,  the  subparagraphs  of  10.1.5.2.1.1  shall  be  structured  as  follows: 

3.2.1 .1  (First  system  state  name) 

3.2.1. 1.1  (System  mode  I) 

3.2.1. 1.1.1  (System  capability  A) 

3.2.1 .1.1.2  (System  capability  B) 

3.2.1 .1  .U  (System  capability  C) 

3.2.1. 1.2  (System  mode  J) 

3.2.1 .1.2.1  (System  capability  W) 

3.2.1. 1.2.2  (System  capability  X) 

etc. 

3.2. 1.2  (Second  system  state  name) 
etc. 
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10.  PREPARATION  INSTRUCTIONS  (continued) 

g.  Document  structure.  This  specification  shall  consist  of  the  following: 

(1)  Cover 

(2)  Title  page 

(3)  Table  of  contents 

(4)  Scope 

(5)  Applicable  documents 

(6)  System  requirements 

(7)  Quality  assurance  provisions 

(8)  Preparation  for  delivery 

(9)  Notes 

(10)  Appendixes. 

10.1.1  Title  page.  The  title  page  shall  contain  the  information  identified  below  in  the  indicated  format: 

[Documen;  control  number  end  date:  Volume  x  of  y  (if  multi-volume)] 

[Rev.  indicator:  date  of  Rev.] 


SYSTEM  SPECIFICATION 
{  OR  SEGMENT  SPECIFICATION  ) 

FOR  THE 

[SYSTEM  NAME] 


CONTRACT  NO.  [contract  number] 
CORL  SEQUENCE  NO.  [CDRL  number] 
Prepared  for: 

[Contracting  Agency  Name,  department  code] 
Prepared  by: 

[contractor  name  end  address] 


_  Acproved  by _ _ 

(Contracting  agency)  (Contractor) 

Cate _ _ _ 
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10.1.2  Table  of  contents.  This  specification  shall  contain  a  table  of  contents  listing  the  title  and  page 
number  of  each  titled  paragraph  and  subparagraph.  The  table  of  contents  shall  then  list  the  title  and 
page  number  of  each  figure,  table,  and  appendix,  in  that  order. 

10.1.3  Scope.  This  section  shall  be  numbered  1  and  shall  be  divided  into  the  following  paragraphs. 

10.1.3.1  Identification.  This  paragraph  shall  be  numbered  1.1  and  shall  contain  the  approved 
identification  number,  title,  and  abbreviation,  if  applicable,  of  the  system  to  which  this  SSS  app  les. 

10.1.3.2  System  overview.  This  paragraph  shall  be  numbered  1.2  and  shall  briefly  state  the  purpose  of 
the  system  to  which  this  SSS  applies. 

10.1.3.3  Document  overview.  This  paragraph  shall  be  numbered  1.3  and  shall  summarize  the  purpose 
and  contents  of  this  document. 

10.1.4  Applicable  documents.  This  section  shall  be  numbered  2  and  shall  be  divided  into  the  following 
paragraphs. 

10.1.4.1  Government  documents.  This  paragraph  shall  be  numbered  2.1.  This  paragraph  shall  begin 
with  one  of  the  following  two  paragraphs,  as  applicable:  (1)  “The  following  documents  of  the 
issue  shown  form  a  part  of  this  specification  to  the  extent  specified  herein.  In  the  event  o  con  i 
between  the  documents  referenced  herein  and  the  contents  of  this  specification,  the  contents  o  t  is 
specification  shall  be  considered  a  superseding  requirement.'  (2)  The  following  documents  o  the 
issue  shown  form  a  part  of  this  specification  to  the  extent  specified  herein.  In  the  event  of  co'i  i  . 
between  the  documents  referenced  herein  and  the  contents  of  this  specification,  the  contents  o  is 
specification  shall  be  considered  a  superseding  requirement,  except  for  specification  (enter  number  o 
next  higher-tiered  specification)  listed  below.*  The  following  paragraph  shall  appear  at  the  conc.usion  o 
the  list  of  documents:  "Copies  of  specifications,  standards,  drawings,  and  publications  require  y 
suppliers  in  connection  with  specified  procurement  functions  should  be  obtained  frorn  the  contracting 
agency  or  as  directed  by  the  contracting  officer."  Government  documents  shall  be  liSied  by  document 
number  and  title  in  the  following  order 

SPECIFICATIONS: 

Federal 

Military 

Other  Government  Agency 

STANDARDS: 

Federal 

Military 

Other  Government  Agency 
DRAWINGS: 

(Where  detailed  drawings  referred  tc  In  a  specification  are  listed  on  an  assembly  drawing,  it  is  only 
necessary  to  list  the  assembly  drawing.) 
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OTHER  PUBLICATIONS; 

Manuals 

Regulations 

Handbooks 

Bulletins 

etc. 

10.1.4.2  Non-Government  documents.  This  paragraph  shall  be  numbered  2.2  and  shall  begin  with  the 
following  paragraph;  The  following  documents  of  the  exact  issue  shown  fomn  a  part  of  this  specification 
to  the  extent  specified  herein.  In  the  event  of  conflict  between  the  documents  referenced  herein  and  the 
contents  of  this  specification,  the  contents  of  this  specification  shall  be  considered  a  superseding 
requirement."  The  source  for  all  documents  not  available  through  normal  Government  stocking  activities 
shall  be  listed.  The  following  paragraph  shall  be  placed  at  the  conclusion  of  the  list  when  applicable; 
Technical  society  and  technical  association  specifications  and  standards  are  generally  available  for 
reference  from  libraries.  They  are  also  distributed  among  technical  groups  and  using  Federal  Agencies." 
Non-Government  documents  shall  be  listed  by  document  number  and  title  in  the  following  order 

SPECIFICATIONS; 

STANDARDS; 

DRAWINGS: 

OTHER  PUBLICATIONS; 

10.1.5  System  requirements.  This  section  shall  be  numbered  3  and  shall  be  divided  into  the  following 
paragraphs  and  subparagraphs  to  specify  the  requirements  for  the  system  to  which  this  specification 
applies. 

10.1.5.1  Definition.  This  paragraph  shall  be  numbered  3.1  and  shall  provide  a  brief  description  of  the 
system.  This  description  shall  address  pertinent  operational,  and  logistical  considerations  and  concepts. 
A  system  diagram  shall  be  provided. 

10.1.5.2  Characteristics.  This  paragraph  shall  be  numbered  3.2  and  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  requirements  for  system  performance  and  physical  characteristics. 

10.1.5.2.1  Performance  characteristics.  This  subparagraph  shall  be  numbered  3.2.1  and  shall  be 
divided  into  the  following  subparagraphs  to  specify  the  system’s  capabilities  in  the  context  of  the  states 
in  which  the  system  can  exist  and  the  modes  of  operation  within  each  state.  Each  capability  of  the 
system  shall  be  specifled  in  a  uniquely  identified  subparagraph  in  order  to  provide  for  objective 
qualification. 

10.1.5.2.1.1  (Stats  name).  This  subparagraph  shall  be  numbered  3.2.1J<  (beginning  with  3.2.1. 1)  and 
shall  identify  and  provide  a  brief  description  of  a  state  in  which  the  system  can  exist  (e.g.,  weapon  idle, 
weapon  ready,  weapon  deployed). 

10.1.5.2.1.1.1  (Mode  name).  This  subparagraph  shall  be  numbered  3.2.1  JCY  (beginning  with  3.2.1. 1.1). 
This  subparagraph  shall  identity  and  provide  a  brief  description  of  a  mode  of  operation  (e.g., 
surveillance,  threat  evaluation,  weapon  assignment,  target  designation  and  acquisition,  fire  control 
resolution)  within  the  system  state  identified  above. 
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10.  PREPARATION  INSTRUCTIONS  (continued) 

10.1.5.2.1.1.1.1  (System  capability  name  and  project  unique  Identifier).  Tbis  subparagraph  shall  be 
numbered  3.2.1.X.Y.Z  (beginning  with  3.2.1.1,1.1),  shall  specify  a  capability  of  the  system  by  name  and 
project  unique  identifier,  and  shall  describe  its  purpose.  This  subparagraph  shall  a  so  i  entity  t  e 
applicable  parameters  associated  with  the  capability  and  shall  express  them  in  measurable  terms.  a 
capability  of  a  mode  has  been  previously  defined,  this  subparag  aph  shall  reference  rather  than  dup  icate 
that  information. 

10.1.5.2.2  System  capability  relationships.  This  subparagraph  shall  be  numbered  3.2.2  and  shall 
summarize  the  relationships  between  system  capabilities  and  the  states  and  modes  of  the  system. 

10.1.5.2.3  External  interface  requirements.  This  paragraph  shall  be  numbered  3.2.3  and  shall  be 
divided  into  the  following  subparagraphs  to  describe  requirements  for  interfaces  with  other  systems. 
Detailed  quantitative  interface  requirements  may  be  defined  in  separate  specifications  or  Inte  ace 
Control  Documents  (ICDs)  and  referenced  herein.  All  referenced  ICDs  are  considered  part  o  t  is 
specification. 

10.1.5.2.3.1  (System  name)  external  interface  description.  This  subparagraph  shall  be  numbered 
3.2.3.x  (beginning  with  3.2.3. 1)  and  shall  identify  an  external  system  with  which  this  system  interfaces. 
This  subparagraph  shall  describe  the  interfaces  to  the  external  system.  This  subparagraph  shall  identify 
the  purpose  of  each  interface  and  shall  describe  the  relationship  between  each  interface  and  the  states 
and  modes  of  the  system.  When  possible,  each  interface  shall  be  specified  in  detailed,  quantitative  terms 
(e.g.,  dimensions,  tolerances,  loads,  speeds,  communications  protocol). 

I0.1.5.2.<t  Physical  characteristics.  This  subparagraph  shall  be  numbered  3.2.4  and  shall  specify  the 
requirements  for  the  physical  characteristics  (e.g.,  weight  limits,  dimensional  limits)  of  the  system. 
Additional  considerations  for  determining  physical  requirements  include: 

a.  Transportation  and  storage 

b.  Security 

c.  Durability 

d.  Safety 

e.  Vulnerability 

f.  Color 

10.1.5.2.4.1  Protective  coatings.  This  subparagraph  shall  be  numbered  3.2.4.1  and  shall  specify,  if 
applicable,  protective  coating  requirements  to  assure  protection  from  corrosion,  abrasion,  or  other 
deleterious  action. 

10.1.5.2.5  System  quality  factors.  This  paragraph  shall  be  numbered  3.2.5  and  shall  ^  divided  into  the 
following  subparagraphs  to  specify  the  applicable  requirements  pertaining  to  system  quality  factors. 

10.1.5.2.5.1  Reliability.  This  subparagraph  shall  be  numbered  3.2.5.1,  shall  specify  reliability 
requirements  in  quantitative  terms,  and  shall  define  the  conditions  under  which  the  reliability 
requirements  are  to  be  met  This  subparagraph  may  include  a  reliability  apportionment  model  to  support 
apportionment  of  reliability  values  assigned  to  system  capabilKies  for  their  share  in  achieving  desired 
system  reliability. 

10.1.5.2.5.2  Maintainability.  This  subparagraph  shall  be  numbered  3.2.5.2  and  shall  specify  quantitative 
maintainability  requirements.  The  requirements  shall  apply  to  maintenance  in  the  planned  maintenance 
and  support  environment  and  shall  be  stated  in  quantitative  terms.  Examples  are: 
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a.  Mean  and  maximum  down  time,  reaction  time,  turnaround  time,  mean  and  maximum  times  to 
repair,  mean  time  between  maintenance  actions. 

b.  Maximum  effort  required  to  locate  and  fix  an  error. 

c.  Maintenance  man-hours  per  flying  hour,  maintenance  man-hours  per  specific  maintenance  action, 
operational  ready  rate,  maintenance  hours  per  operating  hour,  frequency  of  preventative 
maintenance. 

d.  Number  of  people  and  skill  levels,  variety  of  support  equipment. 

e.  Maintenance  costs  per  operating  hour,  man-hours  per  overhaul. 

10.1.5.2.5.3  Availability.  This  subparagraph  shall  be  numbered  3.2.5.3  and  shall  specify  the  degree  to 
which  the  system  shall  be  in  an  operable  and  committable  state  at  the  start  of  the  mission(s),  where  the 
mission(s)  is  called  for  at  an  unknown  (random)  point  in  time. 

10.1.5.2.5.4  Additional  quality  factors.  This  subparagraph  shall  be  numbered  3.2. 5. 4  and  shall  specify 
system  quality  requirements  not  defined  in  the  above  subparagraphs  (e.g.,  integrity,  efficiency,  or 
correctness  requirements  of  the  system). 

10.1.5.2.6  Environmental  conditions.  This  paragraph  shall  be  numbered  3.2.6  and  shall  specify  the 
environmental  conditions  that  the  system  must  withstand  during  transportation,  storage,  and  operation, 
such  as: 


a.  Natural  environment  (e.g.,  wind,  rain,  temperature,  geographic  location) 

b.  Induced  environment  (e.g.,  motion,  shock,  noise,  electromagnetic  radiation) 

c.  Environments  due  to  enemy  action  (e.g.,  over-pressure,  explosions,  radietion). 

10.1.5.2.7  Transportability.  This  subparagraph  shall  be  numbered  3.2.7  and  shall  specify  any  special 
requirements  for  transportation  and  materials  handling.  In  addition,  all  system  elements  that,  due  to 
operational  or  functional  characteristics,  will  be  unsuitable  for  normal  transportation  methods  shall  be 
identified. 

10.1.5.2.8  Flexibility  and  expansion.  This  subparagraph  shall  be  numbered  3.2.8  and  shall  specify  areas 
of  growth  which  require  planning  for  system  flexibility  and  expansion.  In  addition,  this  subparagraph 
shall  specify  specific  system  elements  which  require  spare  capacity  to  support  flexibility  and  expansion. 

10.1.5.2.9  Portability.  This  subparagraph  shall  be  numbered  3.2.9  and  shall  specify  requirements  for 
portability  which  are  applicable  to  the  system  to  permit  employment,  deployment,  and  logistic  support 

10.1.5.3  Design  and  construction.  This  paragraph  shall  be  numbered  3.3  and  shall  be  divided  into 
subparagraohs  that  specify  minimum  system  design  and  constaiclion  standards  which  have  general 
applicability  to  system  equipment  and  are  applicable  to  major  classes  of  equipment  (e.g.,  aerospace 
vehicle  equipment,  and  support  equipment)  or  are  applicable  to  particular  design  standards.  To  the 
maximum  extent  possible,  these  requirements  shall  be  specified  by  incorporation  of  the  established 
military  standards  and  specifications.  Requirements  which  add  to,  but  do  not  conflict  with,  requirements 
specified  herein  may  be  included  in  individual  configuration  item  specifications.  In  addition,  this 
paragraph  shall  specify  criteria  for  the  selection  and  imposition  of  Federal,  military,  and  contraaor 
specifications  and  standards. 

10.1.5.3.1  Materials.  This  subparagraph  shall  be  numbered  3.3.1  and  shall  specify  those  system-peculiar 
requirements  governing  use  of  materials,  parts,  and  processes  in  the  design  of  system  equipment.  Special 
attention  shall  be  directed  to  prevent  unnecessary  use  of  strategic  or  critical  materials.  (A  strategic  and 
critical  materials  list  may  be  obtained  from  the  contracting  agency.)  In  addition,  requirements  for  the 
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use  of  standard  and  commercial  parts  and  parts  for  which  qualified  products  lists  have  been  established 
shall  be  specified  in  this  paragraph. 

10.1.5.3.T.1  Toxic  products  and  formulations.  This  subparagraph  shall  be  numbered  3.3. 1.1  and  shall 
specify  requirements  for  the  control  of  toxic  products  or  formulations  to  be  used  in  the  system  or  to  be 
generated  by  the  system. 

10.1.5.3.2  Electromagnetic  radiation.  This  subparagraph  shall  be  numbered  3.3.2  and  shall  contain 
requirements  pertaining  to  limits  on  the  electromagnetic  radiation  which  the  system  is  permitted  to 
generate. 

10.1.5.3.3  Nameplates  and  product  marking.  This  subparagraph  shall  be  numbered  3.3.3  and  shall 
contain  requirements  for  nameplates,  part  marking,  serial  and  lot  number  marking,  software  media 
marking,  and  other  identifying  markings  required  for  the  system.  Reference  may  be  made  to  existing 
standards  on  the  content  and  application  of  markings. 

10.1.5.3.4  Workmanship.  This  subparagraph  shall  be  numbered  3.3.4  and  shall  specify  workmanship 
requirements  for  equipment  to  be  produced  during  system  development  and  requirements  for  manufacture 
by  production  techniques. 

10.1.5.3.5  Interchangeability.  This  subparagraph  shall  be  numbered  3.3.5  and  shall  specify  the 
requirements  for  system  equipment  to  be  interchangeable  and  replaceable.  Entries  in  this  paragraph  are 
for  the  purpose  of  establishing  a  condition  for  design  and  are  not  to  define  the  conditions  of 
interchangeability  required  by  the  assignment  of  a  part  number. 

10.1.5.3.6  Safety.  This  subparagraph  shall  be  numbered  3.3.6  and  shall  specify  those  safety 
requirements  which  are  basic  to  the  design  of  the  system,  with  respect  to  equipment  characteristics, 
methods  of  operation,  and  environmental  influences.  This  paragraph  shall  also  specify  those  safety 
requirements  y/hich  prevent  personnel  injury  and  equipment  degradation  without  degrading  operational 
capability  (e.g.,  restricting  the  use  of  dangerous  materials  where  possible,  classifying  explosives  for 
purposes  of  shipping,  handling  and  storing,  abort/escape  provisions  from  enclosures,  gas  detection  and 
warning  devices,  grounding  of  electrical  system,  cleanliness  and  decontamination,  explosion  proofing). 

To. 1. 5.3.7  H''man  engineering.  This  subparagraph  shall  be  numbered  3.3.7  and  shall  specify  human 
engineering  requirements  for  the  system  or  for  specific  configuration  items.  This  paragraph  shall 
reference  applicable  documents  (e.g.,  MlL-STD-1472)  and  specify  any  special  or  unique  requirements  (e.g., 
constraints  on  allocation  of  capabilities  to  personnel  and  communications,  and  personnel/equipment 
interactions).  This  paragraph  shall  include  those  specific  areas,  stations,  or  equipment  which  would 
require  concentrated  human  engineering  attention  due  to  the  sensitivity  of  the  operation  or  criticality  of 
the  task;  i.e.,  those  areas  where  the  effects  of  human  enor  would  be  particularly  serious. 

10.1.5J.8  Nuclear  control.  This  subparagraph  shall  be  numbered  3.3.8  and  shall  specify  system 
requirements  for  nuclear  components,  such  as: 

a.  Component  design 

b.  In-flight  control 

c.  Prevention  of  inadve  tent  detonation 

d.  Nuclear  safety  mles. 

10.1.5.3.9  System  security.  This  subparagraph  shall  be  numbered  3.3.9  and  shall  specify  security 
requirements  that  are  basic  to  the  design  of  the  system  with  respect  to  the  operational  environment  of 
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the  system.  This  subparagraph  shall  also  specify  those  security  requirements  necessary  to  prevent 
compromise  of  sensitive  information  or  materials. 


10.1.5.3.10  Government  furnished  property  usage.  This  subparagraph  sha 

shall  specify  any  Government  Furnished  Equipment  (GFE)  to  be  incorporated  into  esys  ern  esign.  n 
addition,  this  paragraph  shall  specify  any  Government  Furnished  Inform^ion  (  )  an  ovemmen 

Furnished  Software  (GFS)  to  be  incorporated  into  the  system.  This  list  shall  identify  the  Government 
furnished  property  by  reference  to  its  nomenclature,  specification  number,  an  /or  pa  num  er.  e 
list  is  extensive,  it  may  be  included  as  an  appendix  to  this  specification  an  re  erence  in  is 
paragraph. 


10.1.5.3.11  Computer  resource  reserve  capacity.  This  subparagraph  shall  be  numbered  3.3.11  and 
shall  specify  the  required  computer  resource  reserve  capacity  (e.g.  memory,  timing,  etc.). 


10.1.5.4  Documentation.  This  paragraph  shall  be  numbered  3.4  and  shall  specify  t  e  requiremen  s  or 
system  documentation  such  as  specifications,  drawings,  technical  manuals,  test  p  ans  an  proce  ures,  an 
installation  instruction  data. 


10.1.5.5  Logistics.  This  paragraph  shall  be  numbered  3.5  and  shall  specify  logishc  considerations  and 
conditions  that  apply  to  the  operational  requirements.  These  considerations  and  con  itions  may  inc  u  e. 


a.  Maintenance 

b.  Transportation  modes 

c.  Supply-system  requirements 

d.  Impact  on  existing  facilities 

e.  Impact  on  existing  equipment. 

10.1.5.6  Personnel  and  training.  This  paragraph  shall  be  numbered  3.6  and  be  divided  into  the  following 
subparagraphs  to  specify  the  requirements  for  personnel  and  training. 

10.1.5.6.1  Personnel.  This  subparagraph  shall  be  numbered  3.6.1  and  shall  specify  personnel 
requirements  which  must  be  integrated  into  system  design.  These  requirements  sha  e  erms 

of  numbers  plus  tolerance  and  shall  be  the  basis  for  contractor  design  and  development  ecisions. 
Requirements  stated  in  this  paragraph  shall  be  the  basis  for  determination  of  system  personne  raining, 
training  equipment,  and  training  facility  requirements.  Personnel  requirements  shall  include. 

a.  Numbers  and  skills  of  support  personnel  for  each  operational  deployment  mode  and  the  intended 
duty  cycle,  both  normal  and  emergency. 

b.  Skills  and  numbers  of  personnel  that  shall  be  allocated  to  the  operation,  maintenance,  and 
control  of  the  system. 

10.1.5.6.2  Training.  This  subparagraph  shall  be  numbered  3.5.2  and  shall  include  the  following  training 
requirements: 

a.  Contractor  and  Government  responsibility  for  training.  This  subparagraph  shall  also  specify  the 
concept  of  how  training  shall  be  accomplished  (e.g.,  school,  contractor  training). 

b.  Equipment  that  will  be  required  for  training  purposes. 

c.  Training  devices  to  be  develcped,  characteristics  of  the  training  devices,  and  training  and  skills 
to  be  developed  through  the  use  of  training  devices. 
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d.  Training  time  and  locations  available  for  a  training  program. 

e.  Source  material  and  training  aids  to  support  the  specified  training. 

10.1.5.7  Characteristics  of  subordinate  elements.  This  paragraph  shall  be  numbered  3.7  and  shall  be 
divided  into  the  following  subparagraphs  to  identify  and  describe  each  segment  cf  the  system.  This 
subparagraph  shall  describe  the  relationships  between  the  segments. 

10.1.5.7.1  (Segment  name  and  project  unique  Identifier). This  subparagraph  shall  be  numbered  3.7X 
(beginning  with  3.7.1)  and  shall  provide  the  following  information  for  the  segment: 

a.  State  the  purpose  of  the  segment 

b.  Provide  a  brief  description  of  the  segment 

c.  Identify  the  system  capabilities  the  segment  performs. 

10.1.5.8  Precedence.  This  paragraph  shall  be  numbered  3.8  and  shall  either  specify  the  order  of 
precedence  of  the  requirements  or  assign  weights  to  indicate  the  relative  importance  of  the  requirements. 

10.1.5.9  Qualification.  This  paragraph  shall  be  numbered  3.9  and  shall  state  the  requirements  for 
verification  or  validation,  as  applicable,  of  capabilities  in  a  specific  application.  Each  qualification  test 
shall  be  identified  in  a  separate  subparagraph  and  the  specific  application  shall  be  described. 
Requirements  shall  be  included  for  the  conditions  of  testing,  the  time  (program  phase)  of  testing,  period 
of  testing,  number  of  items  to  be  to  be  tested,  and  any  other  pertinent  qualification  requirements. 

10.1.5.10  Standard  sample.  This  paragraph  shall  be  numbered  3.10  and,  if  applicable,  shall  describe 
requirements  for  the  production  of  one  or  more  standard  samples.  Standard  samples  shall  be  limited  to 
the  illustration  of  qualities  and  characteristics  that  cannot  be  described  using  detailed  test  procedures  or 
design  data  or  that  cannot  be  definitively  expressed. 

10.1.5.1 1  Preproduction  sample,  periodic  production  sample,  pilot,  or  pilot  lot.  This  paragraph  shall 
be  numbered  3.11  and,  if  applicable,  shall  describe  requirements  for  producing  a  preproduction  or  periodic 
production  sample,  a  pilot  model,  or  a  pilot  lot. 

10.1.6  Quality  assurance  provisions.  This  section  shall  be  numbered  4  and  shall  be  divided  into  the 
following  paragraphs  to  specify  the  requirements  to  show  how  the  requirements  of  sections  3  and  5  shall 
be  satisfied. 

10.1.6.1  Responsibility  for  Inspection.  This  paragraph  shall  be  numbered  4.1  and  shall  assign  resporisi- 
bilities  for  performance  of  inspections  of  delivered  products,  materials,  or  services  for  determining 
compliance  with  all  specified  requirements. 

10.1.6.2  Special  tests  and  examinations.  This  paragraph  shall  be  numbered  4.2  and  shall  specify  any 
special  tests  and  examinations  required  for  sampling,  lot  formation,  qualification  evaluation,  and  any 
other  tests  or  examinations  as  necessary.  Each  test  and  examination  shall  be  described  in  a  separate 
subparagraph. 

10.1.6.3  Requirements  cross  reference.  This  paragraph  shall  be  numbered  4J  and  shall  correlate  each 
system  requirement  in  sections  3  and  5  to  the  quality  assurance  provisions  spedfied  in  section  4.  This 
paragraph  may  reference  a  requirements  cross  reference  table  which  may  be  provided  as  an  appendu  to 
this  specification. 
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10.1.7  Prspdration  for  dolivery.  This  section  shaft  be  numbered  5  and  shall  specify  repuirements  for  the 
preparation  of  the  system  and  all  its  components  for  delivery,  including  packaging  and  handling.  This 
section  shall  include  requirements  to  document  any  non-standard  practices  in  appropriate  system  end  item 
specifications.  This  section  may  impose  requirements  to  comply  with  standard  practice  by  referencing 
appropriate  military  specifications  and  standards  to  be  used  as  the  basis  for  preparing  Section  5  of  each 
specification  for  system  end  items. 

10.1.8  Notes.  This  section  shall  be  numbered  6  and  shall  contain  any  general  information  that  aids  in 
understanding  this  document  (e.g.,  background  information,  glossary).  This  section  shall  contain  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this  document. 

10.1.8.1  Intended  use.  This  paragraph  shall  be  numbered  6.1  and  shall  briefly  state  the  purpose  of  the 
system  to  which  the  SSS  applies  in  terms  of  the  mission  and  threat  addressed  by  the  system. 

10.1.8.1.1  Missions.  This  subparagraph  shall  be  numbered  6.1.1  and  shall  describe  the  missions  of  the 
system  to  the  extent  that  such  missions  affect  design  requirements.  This  description  shall  include 
operational  information,  such  as  tactics,  system  deployment,  operating  locations,  and  facilities. 

10.1.8.1.2  Threat.  This  subparagraph  shall  be  numbered  6.1.2  and  shall  describe  the  characteristics  of 
potential  targets,  the  characteristics  of  current  and  potential  enemy  weapon  capabilities  relevant  to  the 
system,  and  any  additional  threat  considerations  that  affect  the  system  design.  This  information  may  be 
contained  in  a  separate  document  and  referenced  in  this  subparagraph  if  it  is  classified. 

10.1.9  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each  appendix  shall 
be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally  have  been  provided. 
Appendixes  may  be  bound  as  sepa.'ate  documents  for  ease  in  handling.  Appendixes  shall  be  lettered 
alphabetically  (A,  B,  etc.),  and  the  paragraphs  within  each  appendix  be  numbered  as  multiples  of  10  (e.g.. 
Appendix  A  paragraph  10,  10.1,  10.2,  20,  20.1,  20.2,  etc.).  Pages  within  each  appendix  shall  be  numbered 
alpha-numerically  as  follows;  Appendix  A  pages  shall  be  numbered  A-1,  A-2,  A-3,  etc.  Appendix  B 
pages  shall  be  numbered  B-1,  B-2,  B-3,  etc. 
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Diskette  copies  of  Appendix  A,  the  Model  system  specifi¬ 
cation,  are  included  with  this  document.  At  the  end  of  this 
report,  two  diskettes  are  provided  in  IBM  Word  Perfect  5.1  and 
one  diskette  in  Macintosh  Microsoft  Word  4.0H.  The  diskettes 
may  be  used  as  the  starting  baseline  for  any  new  system  speci¬ 
fication  being  prepared.  Should  the  diskettes  be  lost  or  not 
included  with  the  copy  of  the  document  you  receive,  please 
contact  the  document  distribution  center  at  The  Aerospace 
Corporation  Library,  Distribution  and  Control,  to  obtain  a  copy: 

The  Aerospace  Corporation 
Library  Services  Distribution/Control 
(310)  336-7260 
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This  document  represents  a  first  by  providing  software  disks  which  can  help 
you  prepare  a  system  specification  for  a  new  space  system.  Your  comments  and 
recommendations  are  solicited  by  this  office  since  updates  and  modifications  are 
planned.  If  you  wish  to  be  updated  on  future  changes  and/or  have  comments 
please  return  the  comment  sheet  below  to: 

The  Aerospace  Corporation 
System  Engineering  Directorate 
Mall  Station  MS/S65 
P.O.  Box  92957 
Los  Angeles,  CA  90009-2957 


GB-4A  Update  Request/Comment  Form 


Name: _ 

Address: 


Please  provide  updates 


Comments: 


